From nobody Sun Feb 1 09:30:51 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EF01A1A36 for ; Sun, 1 Feb 2015 09:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRvJxLrt_6DX for ; Sun, 1 Feb 2015 09:30:42 -0800 (PST) Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B9A1A89B1 for ; Sun, 1 Feb 2015 09:30:38 -0800 (PST) Received: (qmail 32206 invoked by uid 89); 1 Feb 2015 17:30:36 -0000 Received: by simscan 1.3.1 ppid: 32198, pid: 32202, t: 0.1010s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 1 Feb 2015 17:30:36 -0000 Message-ID: <54CE62BB.9070308@lsces.co.uk> Date: Sun, 01 Feb 2015 17:30:35 +0000 From: Lester Caine User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: saag@ietf.org, ietf-privacy@ietf.org, Time Zone Data Distribution Service References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> <54CC9DB3.6040500@lsces.co.uk> <54CD5886.7020409@cs.ucla.edu> <04F56E6866304E628CA1C45B@cyrus.local> In-Reply-To: <04F56E6866304E628CA1C45B@cyrus.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 17:30:44 -0000 On 01/02/15 20:03, Cyrus Daboo wrote: >>> some devices such as central heating controllers >>> would not need a processor capable of the sort of processing power >>> needed to handle that >> >> Even the lowliest central heating controller can easily handle the entire >> tz database, if only to discard unneeded parts as they're received. >> We're talking kilobytes here, not gigabytes or even megabytes. > > Well in this day and age the IETF really ought to also require an > "Environmental Considerations" section in specs too, alongside > "Security" and "Privacy". If that were a factor here (and I don't see > why it would not be) then clearly sending all the data (and throwing > away all but one) vs sending just one tz is an added impact on power > usage for all devices involved (servers, clients, network hardware). Yes > we are talking about kilobytes per device but you have to multiply that > by the number of devices (which with internet of things is only going to > increase beyond what we have now). > > As with everything there are trade offs involved here. For a personal > device, yes I do want strong privacy for key aspects of data that device > might use (the obvious one being location information). However, for > "fixed" devices, like a wall-clock in an office building, in all > likelihood the exposure of revealing what time zone it is configure to > use is likely small. This is actually a good point. One of the 'cost cutting' exercises IS to eliminate the need for a mains power supply since modern devices need so little power so while power over the network cable is a more recent 'development', many current central heating controllers have a couple of AA batteries and a not to 'replace every few years'. So adding paper displays, they can go to sleep for most of the time and any unnecessary software cycles are a drain :) > At this point I do think it worthwhile to give clients the option to > chose what is appropriate for them given the trade offs. So it does make > sense to provide a "full set of tz data" option in the protocol to allow > clients to get the entire set of current data without exposing which > specific time zone(s) they are actually interested in (which would also > remove the need for them to use etags). How about a "getall" action > using a /allzones URI to retrieve all the data. The only tricky part > might be explaining how the data is returned. For iCalendar-based > formats that is easy as multiple VTIMEZONEs would be included in a > single VCALENDAR calendar object. For the binary tz data format, I am > not sure whether simply concatenating the binary data for all tzs is > valid - that is something that that format will need to be clear about. One thing that I have only just twigged is that what we are talking about here is just sending the one data package with everything in! If something is not spelt out it is often missed. I still see the 'power saving' capabilities of a 'changed since' data package flagging centrally just which TZis's need to be looked at, and a complete diff package rather than a full dump again would reduce packet size, but there is no security risk from that either way? I still see the major advantage of tzdist in it's ability to flag that something needs looking at. If I'm not following the affected TZid's then it's up to me if I even update, but I only really see that being necessary if there are several competing publishers each using their own set of data for some 'political or commercial' reason so while we select a default local one, third party material may well need our accessing other services :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk From nobody Sun Feb 1 13:29:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509B61A1A9D; Sun, 1 Feb 2015 13:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TrOOF0Ap9cC; Sun, 1 Feb 2015 13:29:45 -0800 (PST) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC631A00F6; Sun, 1 Feb 2015 13:29:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 396B5A60052; Sun, 1 Feb 2015 13:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDBbP5RlSdRh; Sun, 1 Feb 2015 13:29:43 -0800 (PST) Received: from [192.168.1.9] (pool-173-55-11-52.lsanca.fios.verizon.net [173.55.11.52]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id B08F9A60051; Sun, 1 Feb 2015 13:29:43 -0800 (PST) Message-ID: <54CE9AC3.5060501@cs.ucla.edu> Date: Sun, 01 Feb 2015 13:29:39 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Cyrus Daboo , Lester Caine , Daniel Kahn Gillmor , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> <54CC9DB3.6040500@lsces.co.uk> <54CD5886.7020409@cs.ucla.edu> <04F56E6866304E628CA1C45B@cyrus.local> In-Reply-To: <04F56E6866304E628CA1C45B@cyrus.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 21:29:46 -0000 Cyrus Daboo wrote: > it does make sense to provide a > "full set of tz data" option in the protocol to allow clients to get the entire > set of current data without exposing which specific time zone(s) they are > actually interested in (which would also remove the need for them to use etags). Yes. Although clients could omit etags, my guess is that it'd be OK in most cases privacy-wise to use them, so long as the etags are global (one per tz database version, e.g., "tz2015a") rather than per-server-and-database-version (e.g., "tz2015a-04F56E6866304E628CA1C45B"). That way, etags should provide little tracking info. A bonus is that a client could switch servers without having to re-get the tz database from the new server. > For the binary tz data format, I am not sure > whether simply concatenating the binary data for all tzs is valid It's not, unfortunately. Concatenation works for tzdata sources (so long as all identifiers are unique), but not for tzdata binaries. Operating system updates solve this by shipping tarballs, perhaps with some other info thrown in. One thought is to add to the tz distribution, so that it also contains a single smallish source file that represents all the tz data. This file could be distributed via tzdist and clients could then run the equivalent of 'zic' to convert it to binary form, if that's what they want. This should be more compact than shipping binary files. The new source file would be in addition to the existing source files, which would not need to change (this is for backward compatibility to existing build procedures). This part should be fairly easy to arrange. From nobody Mon Feb 2 00:54:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ED01A006D for ; Mon, 2 Feb 2015 00:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E96hN2co0wkl for ; Mon, 2 Feb 2015 00:54:37 -0800 (PST) Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959061A0076 for ; Mon, 2 Feb 2015 00:54:35 -0800 (PST) Received: (qmail 11085 invoked by uid 89); 2 Feb 2015 08:54:33 -0000 Received: by simscan 1.3.1 ppid: 11079, pid: 11082, t: 0.0911s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 2 Feb 2015 08:54:33 -0000 Message-ID: <54CF3B49.5040705@lsces.co.uk> Date: Mon, 02 Feb 2015 08:54:33 +0000 From: Lester Caine User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: saag@ietf.org, ietf-privacy@ietf.org References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> <54CC9DB3.6040500@lsces.co.uk> <54CD5886.7020409@cs.ucla.edu> <04F56E6866304E628CA1C45B@cyrus.local> <54CE9AC3.5060501@cs.ucla.edu> In-Reply-To: <54CE9AC3.5060501@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 08:54:39 -0000 On 01/02/15 21:29, Paul Eggert wrote: >> it does make sense to provide a >> "full set of tz data" option in the protocol to allow clients to get >> the entire >> set of current data without exposing which specific time zone(s) they are >> actually interested in (which would also remove the need for them to >> use etags). > > Yes. Although clients could omit etags, my guess is that it'd be OK in > most cases privacy-wise to use them, so long as the etags are global > (one per tz database version, e.g., "tz2015a") rather than > per-server-and-database-version (e.g., > "tz2015a-04F56E6866304E628CA1C45B"). That way, etags should provide > little tracking info. A bonus is that a client could switch servers > without having to re-get the tz database from the new server. A debate on how an etag is generated on another list implies that is should include a hash of the data, but I am sure that the spec does not require that and allows a fully defined etag? The strong/weak element could come into play where the 'style' of data is an addition, but every reply with a 'tz2015a' head would contain the same core data (ignoring backzone problem). I'm not sure if that is necessary if the request identifies the correct style required, but either way the tag itself is generic world wide and can be accepted when a different server has to be accessed for any reason. In the context of the 'changedsince', asking for 'latest' where one is currently using 'tz2014j' will return a new packet with 'tz2015a' while asking for 'changedsince=tz2014j' will return just the differences. If 'latest' returns a complete data dump then the local machine has to work out if there are any changes which require further work, while the difference set if sent as a simple list of TZid's allows the client to ignore any update they are not using id's from. It is up to them if they download a 'full dump', just the TZid's that have changed, or only the one's they are using. For embedded devices asking for a simple 'expand' etag will give them a 'same' message until the version changes. If there is a version change, but it does not affect the content of this particular packet then one could say that they don't need to do anything, but given that this is such a rare occurrence, simply downloading again is fine. If the client does need to know if the next transition has changed then that is best handled locally. For this action I don't see that downloading a complete data set is necessary at all? Since the cache mechanism will time out at regular intervals, even the etag mechanism will give a reply when nothing has changed? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk From nobody Mon Feb 2 08:01:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9251A89E0; Sun, 1 Feb 2015 09:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luFtjxH6t9V7; Sun, 1 Feb 2015 09:03:37 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263E01A899A; Sun, 1 Feb 2015 09:03:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 85F05A95403; Sun, 1 Feb 2015 12:03:34 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eRo8kJ7ppp1; Sun, 1 Feb 2015 12:03:34 -0500 (EST) Received: from [10.1.0.120] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 00CEDA953F8; Sun, 1 Feb 2015 12:03:32 -0500 (EST) Date: Sun, 01 Feb 2015 12:03:30 -0800 From: Cyrus Daboo To: Paul Eggert , Lester Caine , Daniel Kahn Gillmor , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear Message-ID: <04F56E6866304E628CA1C45B@cyrus.local> In-Reply-To: <54CD5886.7020409@cs.ucla.edu> References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> <54CC9DB3.6040500@lsces.co.uk> <54CD5886.7020409@cs.ucla.edu> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2294 Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 08:01:02 -0800 Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 17:03:39 -0000 Hi Paul, --On January 31, 2015 at 2:34:46 PM -0800 Paul Eggert wrote: >> some devices such as central heating controllers >> would not need a processor capable of the sort of processing power >> needed to handle that > > Even the lowliest central heating controller can easily handle the entire > tz database, if only to discard unneeded parts as they're received. > We're talking kilobytes here, not gigabytes or even megabytes. Well in this day and age the IETF really ought to also require an "Environmental Considerations" section in specs too, alongside "Security" and "Privacy". If that were a factor here (and I don't see why it would not be) then clearly sending all the data (and throwing away all but one) vs sending just one tz is an added impact on power usage for all devices involved (servers, clients, network hardware). Yes we are talking about kilobytes per device but you have to multiply that by the number of devices (which with internet of things is only going to increase beyond what we have now). As with everything there are trade offs involved here. For a personal device, yes I do want strong privacy for key aspects of data that device might use (the obvious one being location information). However, for "fixed" devices, like a wall-clock in an office building, in all likelihood the exposure of revealing what time zone it is configure to use is likely small. At this point I do think it worthwhile to give clients the option to chose what is appropriate for them given the trade offs. So it does make sense to provide a "full set of tz data" option in the protocol to allow clients to get the entire set of current data without exposing which specific time zone(s) they are actually interested in (which would also remove the need for them to use etags). How about a "getall" action using a /allzones URI to retrieve all the data. The only tricky part might be explaining how the data is returned. For iCalendar-based formats that is easy as multiple VTIMEZONEs would be included in a single VCALENDAR calendar object. For the binary tz data format, I am not sure whether simply concatenating the binary data for all tzs is valid - that is something that that format will need to be clear about. -- Cyrus Daboo From nobody Mon Feb 2 08:32:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AFD1A6FF0; Mon, 2 Feb 2015 08:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIjVEwNU9ukP; Mon, 2 Feb 2015 08:32:20 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BD4E01A1B43; Mon, 2 Feb 2015 08:32:20 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CC99CF984; Mon, 2 Feb 2015 11:32:17 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id CDF6420222; Mon, 2 Feb 2015 11:32:15 -0500 (EST) From: Daniel Kahn Gillmor To: Eliot Lear , Daniel Migault , saag@ietf.org, ietf-privacy@ietf.org In-Reply-To: <54CCC5BA.9090101@cisco.com> References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CCC5BA.9090101@cisco.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 02 Feb 2015 11:32:15 -0500 Message-ID: <877fw0gtps.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:32:23 -0000 Hi Eliot-- thanks for the feedback. On Sat 2015-01-31 07:08:26 -0500, Eliot Lear wrote: > I think there are several categories of issues that you've raised, and > I'd like to break them out. The first is the easy category: that which > has been raised before and considered. There is only one issue in that > category as to whether or not everything should run atop TLS. That > issue need not be reconsidered, EXCEPT in as much as you have clarified > the context (c2s versus s2s). Clarifying the c2s vs. s2s scenarios for TLS would definitely be useful. > There is another category of that which really must change. Most (if > not all) of what you mark as security is in this category. The > downgrade attack that is possible in the current text also does not > match my understanding of the consensus of the working group. That is- > either a client uses HTTP or it uses HTTPS, but it may not "try" HTTPS > first, and then back off to HTTP. "Do. Do not. There is no try." If we can spell this out explicitly in the draft, that would be good. I wonder if this is maybe something that would contribute to the idea of "profiles of operation". If there is a profile for low-power, in-network devices, that profile could allow HTTP access, restricting fetches from the local network's tzdist provider, and accept the linkability implications (and the resulting lack of privacy for the device). This would suggest a second profile for other devices: those that have higher bandwidth available, more compute power, and should not be willing to make the linkability/privacy tradeoff in the same way. Is there a third profile, some sort of device, service, or operating system that fits in the middle here? Naming the profiles explicitly and being clear which features of the spec are intended for which profile might make the privacy considerations easier to write. It might also turn out that there are features that fit in no realistic profile, and can therefore be dropped to simplify the spec. > The other issues break down into two groups, I think. Authenticated > sessions versus unauthenticated sessions. Because authentication is > allowed, and because we do not specify a provisioning mechanism, likely > there will be linkage between services. But we should also be mindful > of what mitigations are truly available to us with regard to the other > functions. Authenticated sessions clearly provide linkability between repeat sessions of the same client to the server. Depending on other choices made by the network configurations involved (e.g. the use of stable TLS session IDs, or padding/timeskew choices), those sessions may *also* leak some linkable information to a passive network attacker (i haven't yet considered an active network attacker whose goal is to link sessions). But unauthenticated sessions are not necessarily unlinkable, either to the Provider, or to a network observer. If the goal is unlinkability, unauthenticated sessions are probably necessary but not sufficient. It's important that the draft be clear about this. --dkg From nobody Mon Feb 2 11:14:26 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009A11A1A42; Mon, 2 Feb 2015 11:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfQtoxJrRgGL; Mon, 2 Feb 2015 11:13:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6DC1A1A46; Mon, 2 Feb 2015 11:13:38 -0800 (PST) Received: from [192.168.2.105] ([79.246.19.23]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MOw4N-1YKqsp1qkh-006KeN; Mon, 02 Feb 2015 20:13:36 +0100 Message-ID: <54CFCC5F.6080709@gmx.net> Date: Mon, 02 Feb 2015 20:13:35 +0100 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Harrington References: <54BB6D67.6010509@gmx.net> <23D534A9-90E7-45C0-AE78-419617965D15@comcast.net> In-Reply-To: <23D534A9-90E7-45C0-AE78-419617965D15@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:D8XI1M81zqUQs/mD82mPNbovlVl+YhAB2M0BxmN6l+yef3I72Gm RBmqa8MIcSSPBmRuo7euT1KgU7SC6+22Hjsqb0m6UnLMWHWBoauPK3DMWFpN6c30gf3rJD9 wxDyLGVHK3wydOcPCfyFxUTkuudUJjmthFo7XtAwkYOgtjMustNP/mZQRiujTXbB4Ky9Six bzZn7HNj623gks1pjxXkw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: ietf@ietf.org, OPSAWG@ietf.org, Lime@ietf.org, sacm@ietf.org, saag@ietf.org Subject: Re: [saag] [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:13:51 -0000 Dear David, thanks for your hint to the SACM WG. I have also posted it within the SACM community for any comments, feedback, suggestions, notations, hints, recommendations, etc. but haven´t received any response or feedback to the Internet Draft so far. I hope this will change and a lively discussion is going to come up. Kind regards B.-C. Boesch Am 02.02.2015 um 18:32 schrieb David Harrington: > I think similar work is being addressed in the sacm wg. > > David Harrington > ietfdbh@comcast.net > > > > On Jan 18, 2015, at 3:23 AM, B.-C. Boesch wrote: > >> Dear Community, >> >> Efficiency of Intrusion Detection Systems (IDS) depends on their configuration and coverage of services. The coverage depends on used IDS with currently vendor-specific configurations. In case of usage of multiple systems the operations could become complex. Individual Communication between management interface and the IDS entities results that current multi-vendor IDS architectures do not interact with each other. They are independent coexistent. >> >> The Internet Draft defines data formats and exchange procedures to standardize parametrization information exchange into intrusion detection and response systems from a Manager to an Analyzer. >> >> The created Intrusion Detection Parametrization Exchange Format (IDPEF) is intended to be a standard data format to parametrize IDS. The development of this open standardized format and the Intrusion Detection Message Exchange Format (IDMEF) will be enable in combination interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal IDS implementation. >> >> The most obvious place to implement IDPEF is in the data channel between a Manager and an Analyzer of an IDS within this data channel where the Manager sends the configuration parameters to the Analyzers. But there are other places where the IDPEF can be useful: >> >> - Combination of specialized IDS like application-IDS with server-IDS, WLAN-IDS and network-IDS to one functional interacting meta-IDS. >> >> - Management of different IDS vendors with one central management interface. >> >> - Interaction of different IDS by using IDPEF and IDMEF. >> >> - Parametrization backups and restore of parametrized IDS entities. >> >> - For a communication between a Manager and a Manager in a multi-stage management architecture. >> >> I am happy to invite you to give me feedback, suggestions, notations, hints, recommendations, etc. to improve the Internet Draft. The initial version of the Internet Draft could be found at: >> >> http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt >> >> Kind regards, >> >> B.-C. Boesch >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Feb 4 07:51:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C511A8AC1; Wed, 4 Feb 2015 07:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23xqXnwAAOE5; Wed, 4 Feb 2015 07:51:01 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087391A8AB5; Wed, 4 Feb 2015 07:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423065061; x=1454601061; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qw8xDlX4JBK6d1OcLcNDMjqofI0jWKPjrgCt151x8JQ=; b=qGI+cVGKgQbX2rGxW+/hocLrjmDfjF5bGtv9Jl9EhLxWTOZ14GVfaTy9 i9b6BIqCmY1g32kKy0TkSqNusXxYx3P6XUxYQNuAjlxiT1ZBoK6LxOsOc 6qfe0eLtisSKEIOdTBg0MJwxlQTQeAA2pQLi+fiDIP72qjPUdV4jizcc6 s=; X-IronPort-AV: E=McAfee;i="5600,1067,7701"; a="83472930" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2015 07:51:00 -0800 X-IronPort-AV: E=Sophos;i="5.09,518,1418112000"; d="scan'208";a="898391163" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Feb 2015 07:50:59 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 4 Feb 2015 07:50:58 -0800 Message-ID: <54D23FDE.3020401@qti.qualcomm.com> Date: Wed, 4 Feb 2015 09:50:54 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Nico Williams References: <20141217230150.GB9443@localhost> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: Darren J Moffat , Stef Walter , "ietf@ietf.org" , "saag@ietf.org" , Jan Pechanec , Nikos Mavrogiannopoulos Subject: [saag] My IESG Eval for draft-pechanec-pkcs11uri-19 (Was: PKCS#11 URI slot attributes & last call) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:51:03 -0000 Normally I would just put this in my ballot, but since a change was made due to a Last Call comment that was discussed here (a discussion I missed at the time) I want to comment on this here to make sure there is consensus for either the change you made, or for what I will propose: On 12/19/14 6:06 PM, Nico Williams wrote: > One thing I just noticed is that you allow Unicode. You might want to > reference RFC3987 (IRIs), for, e.g., advice as to normalization. > This seems like an exceedingly bad idea to me, for a number of reasons: 1. The use of IRIs as protocol elements is recipe for disaster. I think we came to the conclusion long ago that if you are using something as a protocol element, it had better be a URI, and you had better percent-encode anything that was non-US-ASCII. 2. Normalization is discussed quite reasonably in 3986; 3987 is unlikely to add anything useful. 3. The 3987 is currently in a state of limbo. We're waiting to see what W3C ends up recommending for HTML5, and the IETF is likely to end up referencing that in the long run and not 3987. Unless folks want to express a strong reason for this particular document to reference 3987, I really think you should remove any reference to it. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Feb 4 08:28:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D081A0451 for ; Wed, 4 Feb 2015 08:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqcy7zq93iml for ; Wed, 4 Feb 2015 08:28:22 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C131A03A0 for ; Wed, 4 Feb 2015 08:28:22 -0800 (PST) Received: from latte.josefsson.org (c-04f7e555.014-1001-73746f1.cust.bredbandsbolaget.se [85.229.247.4]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t14GSHsw007586 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 4 Feb 2015 17:28:18 +0100 X-Hashcash: 1:22:150204:saag@ietf.org::eGpDYPsr+nd2MXxJ:GxP7 From: Simon Josefsson To: saag@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Wed, 04 Feb 2015 17:28:16 +0100 Message-ID: <87386ly733.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [saag] PKCS#5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 16:28:24 -0000 --=-=-= Content-Type: text/plain Hi. RFC 2898 (PKCS#5 v2.0) has not been updated for SHA2 in the RFC series, and PBKDF2 is often used with HMAC-SHA256 these days. RSA/EMC appears to have published version 2.1 of PKCS#5 at some point, but the links on the following page are dead. I believe HMAC-SHA2 was included in this update. http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-5-password-based-cryptography-standard.htm Is there interest in updating RFC 2898 to include HMAC-SHA256, possibly matching version 2.1 of PKCS#5? It would be useful to add test vectors for this. One problematic aspect may be this quote in RFC 2898: This memo represents a republication of PKCS #5 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. Change control for several other PKCS documents have been turned over to the IETF, so I'm hoping this can be resolved. I'm not certain SAAG is the best group for this discussion, but I couldn't think of any more appropriate list. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU0kigAAoJEIYLf7sy+BGdIDkH/iRn8Beil6uDAhWKLZ1/axlg RCoLOSD8c6tJSfuwUxj7XuXx0kKOigYSxtssw2K6puGdApQdsL62KV+m8gg203Jx IE0mkMRlIeo2QoW4Dsu6BdhFqY5RUOxO26sUOOxdljBw2wpvbsGp0i5ZUNSB4bIA m2RvKvqxJybv5qlFa2sC+Cgl4lnNs5eWRn7y9kQT8/qVdfJXscLgTZEuZM8Hqfc5 UAUPwYovUOUGAgTTjPi/1tG/3eHYDPwnazXgiDLMCe7JMfo7dcYxUjDcyTkTcgbp 5WKvKWcg97hOgfKAzvmjVYyGzxwRAkNjKwoiOrHYIS6k/FfCULEoqWWnF+wvSIk= =jZHa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 4 08:33:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE57F1A049A; Wed, 4 Feb 2015 08:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpIyBpXFmv1S; Wed, 4 Feb 2015 08:33:26 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BBA1A87DB; Wed, 4 Feb 2015 08:33:23 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YJ2t7-000LVy-5M; Wed, 04 Feb 2015 11:33:13 -0500 Date: Wed, 04 Feb 2015 11:33:08 -0500 From: John C Klensin To: Pete Resnick , Nico Williams Message-ID: <0BA0559819A5545DC09606CA@JcK-HP8200.jck.com> In-Reply-To: <54D23FDE.3020401@qti.qualcomm.com> References: <20141217230150.GB9443@localhost> <54D23FDE.3020401@qti.qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Darren J Moffat , Stef Walter , ietf@ietf.org, saag@ietf.org, Jan Pechanec , Nikos Mavrogiannopoulos Subject: Re: [saag] My IESG Eval for draft-pechanec-pkcs11uri-19 (Was: PKCS#11 URI slot attributes & last call) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 16:33:28 -0000 +1 Given what I believe has been referred to recently as "the kerfluffle", it is not clear whether the advice about normalization in 3986 is really adequate either, but it appears to me that is close enough for this document and, as you suggest, clearly better than making a new reference to 3987. john --On Wednesday, February 04, 2015 09:50 -0600 Pete Resnick wrote: > Normally I would just put this in my ballot, but since a > change was made due to a Last Call comment that was discussed > here (a discussion I missed at the time) I want to comment on > this here to make sure there is consensus for either the > change you made, or for what I will propose: > > On 12/19/14 6:06 PM, Nico Williams wrote: >> One thing I just noticed is that you allow Unicode. You >> might want to reference RFC3987 (IRIs), for, e.g., advice as >> to normalization. >> > > This seems like an exceedingly bad idea to me, for a number of > reasons: > > 1. The use of IRIs as protocol elements is recipe for > disaster. I think we came to the conclusion long ago that if > you are using something as a protocol element, it had better > be a URI, and you had better percent-encode anything that was > non-US-ASCII. > > 2. Normalization is discussed quite reasonably in 3986; 3987 > is unlikely to add anything useful. > > 3. The 3987 is currently in a state of limbo. We're waiting to > see what W3C ends up recommending for HTML5, and the IETF is > likely to end up referencing that in the long run and not 3987. > > Unless folks want to express a strong reason for this > particular document to reference 3987, I really think you > should remove any reference to it. > > pr From nobody Thu Feb 5 08:14:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3801A8761 for ; Thu, 5 Feb 2015 08:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmsewHxcLAC9 for ; Thu, 5 Feb 2015 08:14:32 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CC71A00DF for ; Thu, 5 Feb 2015 08:14:32 -0800 (PST) Received: from BL2PR03MB467.namprd03.prod.outlook.com (10.141.92.23) by BL2PR03MB129.namprd03.prod.outlook.com (10.255.230.20) with Microsoft SMTP Server (TLS) id 15.1.87.13; Thu, 5 Feb 2015 16:14:30 +0000 Received: from BL2PR03MB467.namprd03.prod.outlook.com ([10.141.92.23]) by BL2PR03MB467.namprd03.prod.outlook.com ([10.141.92.23]) with mapi id 15.01.0065.013; Thu, 5 Feb 2015 16:14:31 +0000 From: Anoosh Saboori To: "saag@ietf.org" Thread-Topic: [saag] PKCS#5 Thread-Index: AQHQQJeeW1GPMITyH0auJgA+IbCA9pzg50tQgAADVVCAAAesgIAABqvggAAAlJCAACtjsIABFgXw Date: Thu, 5 Feb 2015 16:14:30 +0000 Message-ID: References: <87386ly733.fsf@latte.josefsson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.43] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB129; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB129; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(243025005)(19300405004)(86362001)(33656002)(87936001)(86612001)(19580405001)(19580395003)(2656002)(2950100001)(77096005)(2900100001)(66066001)(76176999)(15975445007)(50986999)(92566002)(102836002)(551544002)(54356999)(74316001)(62966003)(77156002)(2501002)(2351001)(106116001)(122556002)(93886004)(40100003)(110136001)(76576001)(46102003)(99286002)(568214008)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB129; H:BL2PR03MB467.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2015 16:14:30.9937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB129 Archived-At: Cc: =?iso-8859-1?Q?Magnus_Nystr=F6m?= Subject: Re: [saag] PKCS#5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:14:35 -0000 Hello, You can find the link to v2.1 of PKCS#5 below: http://www.emc.com/collateral/white-papers/h11302-pkcs5v2-1-password-based-= cryptography-standard-wp.pdf=20 Microsoft supports this effort.=20 As for control issues, PKCS#12 was recently converted to RFC so it should b= e an easy to task to take v2.1 of PKCS#5 and update RFC 2898. Below is RFC = 7292 that corresponds to PKCS#12. http://www.rfc-editor.org/rfc/rfc7292.txt=20 -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Simon Josefsson Sent: Wednesday, February 4, 2015 8:28 AM To: saag@ietf.org Subject: [saag] PKCS#5 Hi. RFC 2898 (PKCS#5 v2.0) has not been updated for SHA2 in the RFC series, and= PBKDF2 is often used with HMAC-SHA256 these days. RSA/EMC appears to have= published version 2.1 of PKCS#5 at some point, but the links on the follow= ing page are dead. I believe HMAC-SHA2 was included in this update. http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-5-password-= based-cryptography-standard.htm Is there interest in updating RFC 2898 to include HMAC-SHA256, possibly mat= ching version 2.1 of PKCS#5? It would be useful to add test vectors for th= is. One problematic aspect may be this quote in RFC 2898: This memo represents a republication of PKCS #5 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. Change control for several other PKCS documents have been turned over to th= e IETF, so I'm hoping this can be resolved. I'm not certain SAAG is the best group for this discussion, but I couldn't = think of any more appropriate list. /Simon From nobody Thu Feb 5 08:57:51 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5D91A897D for ; Thu, 5 Feb 2015 08:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMTTpxU-dfNH for ; Thu, 5 Feb 2015 08:57:39 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3943F1A040C for ; Thu, 5 Feb 2015 08:57:23 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id f15so9321667lbj.5 for ; Thu, 05 Feb 2015 08:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mfp5HuJeZVtRPEztzw81Tv3U9/uA3l2zWBLKMVVVj50=; b=TGpt1fpGNK7MgScX7nRoIRQ3h9yx4Ma7K7/lCTPdDSv4bRzJg9hX8IzeDefz3Pg0wb h1wKt0KpMxIxEEgXAiK2K2YG7cmXHnGc/EmccyoToWCtTE0/bCs64CF26piDfK5RKjcI 7yADMxnsTmrNxCWJrGUHDqWjCzwNxANqmESW+NptY02GrizvabcDx17B2fZy2YdF/D66 RIBbF4bMa9rZk3FTnVYfdWXJ7Ic7287CjrJZZHsjm8BkdAk+OKvMcJYUlWpxuDX66gWb m/f7l3NcZUBxg993qgM6+E0qBUm1L5mnPtPc+NhpxjRihCp1zi8+UVdnWSw5Al1LHXl+ 0cOA== MIME-Version: 1.0 X-Received: by 10.152.7.38 with SMTP id g6mr4839931laa.65.1423155441673; Thu, 05 Feb 2015 08:57:21 -0800 (PST) Received: by 10.112.167.134 with HTTP; Thu, 5 Feb 2015 08:57:21 -0800 (PST) In-Reply-To: References: <87386ly733.fsf@latte.josefsson.org> Date: Thu, 5 Feb 2015 11:57:21 -0500 Message-ID: From: Kathleen Moriarty To: Anoosh Saboori Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= , "saag@ietf.org" Subject: Re: [saag] PKCS#5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:57:49 -0000 Hi, This is something I was working on, getting PKCS#1 and #5 over to the IETF. This is pending on some internal stuff, really just management changes. I had the approval from execs that are no longer with us and got it right before they left... I'll restart the internal process. Basically, we would do the same thing as #12, publish a version, then more changes happen in a subsequent iteration. On Thu, Feb 5, 2015 at 11:14 AM, Anoosh Saboori wr= ote: > Hello, > > You can find the link to v2.1 of PKCS#5 below: > > http://www.emc.com/collateral/white-papers/h11302-pkcs5v2-1-password-base= d-cryptography-standard-wp.pdf > > Microsoft supports this effort. > > As for control issues, PKCS#12 was recently converted to RFC so it should= be an easy to task to take v2.1 of PKCS#5 and update RFC 2898. Below is RF= C 7292 that corresponds to PKCS#12. > > http://www.rfc-editor.org/rfc/rfc7292.txt > > > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Simon Josefsson > Sent: Wednesday, February 4, 2015 8:28 AM > To: saag@ietf.org > Subject: [saag] PKCS#5 > > Hi. > > RFC 2898 (PKCS#5 v2.0) has not been updated for SHA2 in the RFC series, a= nd PBKDF2 is often used with HMAC-SHA256 these days. RSA/EMC appears to ha= ve published version 2.1 of PKCS#5 at some point, but the links on the foll= owing page are dead. I believe HMAC-SHA2 was included in this update. > > http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-5-passwor= d-based-cryptography-standard.htm > > Is there interest in updating RFC 2898 to include HMAC-SHA256, possibly m= atching version 2.1 of PKCS#5? It would be useful to add test vectors for = this. > > One problematic aspect may be this quote in RFC 2898: > > This memo represents a republication of PKCS #5 v2.0 from RSA > Laboratories' Public-Key Cryptography Standards (PKCS) series, and > change control is retained within the PKCS process. > > Change control for several other PKCS documents have been turned over to = the IETF, so I'm hoping this can be resolved. > > I'm not certain SAAG is the best group for this discussion, but I couldn'= t think of any more appropriate list. > > /Simon > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Best regards, Kathleen From nobody Wed Feb 11 17:25:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731361A89A6; Wed, 11 Feb 2015 17:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIJ_cTIY1P-r; Wed, 11 Feb 2015 17:24:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E30D1A8994; Wed, 11 Feb 2015 17:24:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40652BF07; Thu, 12 Feb 2015 01:25:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCgbQgAljB-Z; Thu, 12 Feb 2015 01:25:07 +0000 (GMT) Received: from [172.16.29.97] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 634D6BEEE; Thu, 12 Feb 2015 01:25:06 +0000 (GMT) Message-ID: <54DC00D0.2050900@cs.tcd.ie> Date: Thu, 12 Feb 2015 01:24:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "saag@ietf.org" , "kitten@ietf.org" , "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "kitten@ietf.org" List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:24:47 -0000 Hiya, I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's needed for some work in http-auth but doesn't quite fit with any current WG. I plan to start an IETF LC for that shortly, but please do let me know if there are any issues. This was previously discussed on the kitten WG list, so (with the WG chairs' permission) I'd ask that you send any comments there if you've any before I start the IETF LC. (Reply-to is set to the kitten WG list.) Thanks, S. [1] https://tools.ietf.org/html/draft-hansen-scram-sha256 From nobody Fri Feb 13 09:23:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABDD1A8761; Fri, 13 Feb 2015 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.622 X-Spam-Level: ** X-Spam-Status: No, score=2.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qaoksSko2VU; Fri, 13 Feb 2015 09:23:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA201A0162; Fri, 13 Feb 2015 09:23:18 -0800 (PST) Received: from [192.168.2.100] ([79.246.51.108]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M3d9B-1XW0O20QQD-00rHSb; Fri, 13 Feb 2015 18:23:15 +0100 Message-ID: <54DE32FF.5030504@gmx.net> Date: Fri, 13 Feb 2015 18:23:11 +0100 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jerome Athias , sacm@ietf.org, saag@ietf.org, ietf@ietf.org, OPSAWG@ietf.org References: <54BB6D67.6010509@gmx.net> <23D534A9-90E7-45C0-AE78-419617965D15@comcast.net> <54CFCC5F.6080709@gmx.net> <54D12183.2090105@gmx.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040006060109020703050002" X-Provags-ID: V03:K0:axO4E17ajvDU1oagUwCaFzpMyMr+mQrEWbN7PSE28lnqRF2iWPs MOeHXgchTlbKCLhK4yGQ55flks72ZZd8m6ylbmqrEPFf6U9/N3UL8r/bbogVarLoJ81Yr5t RfpaGQ4DQUovy85f3X6D62Bxs9gCvI2Z62aj+bDDqX6SQ83dTWqhw8QsxaXcpJnn4GPk9Tu o5XhXsctsgwHiDB2jMYpA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [saag] [sacm] [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:23:22 -0000 This is a multi-part message in MIME format. --------------040006060109020703050002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jerome, thanks for your feedback and support to align "contact" with "3.10. Contact Class" of RfC 5070 (IODEFv2). I had lots of thoughts about**your recommendation and currently I am not sure if this is the best choice. The IODEFv2 is focussed on exchange and handle of incident information by CSIRT humans (maybe with systems support and so it should be parsable). So more than one contact could be helpful to handle the incident. Also it must be flexible to use it for any kind of contact. IDMEF (RfC 4765) is focused on signalling of events / incidents within an IDS or its user interface. The IDPEF as Internet Draft is intended to parametrize the Analyzer of an IDS (communication between Manager and Manager or Analyzer). The information handler use the information which is presented to him by the format. Focused on the contact class for the field service and the technical contact there will be a single point of contact. The contact node of IDPEF provides multiple contact channels for the field service or a second level service / technical administration where other information like postal address or contact name is located in upper nodes. So This could be the input for IDMEF / IODEF and should predefine to information for this two support contacts of an entity. And there is always one group exclusive responsible for this job. IMHO this kind of detailed structured information supports that all information are present. With a machine-machine interaction this could be checked automatically. On the other hand an Analyzer is able to combine or chain these values for IDMEF / IODEF with less efforts, but maybe in any cases not the complete information is needed. I am aware that IDPEF and its structure (especially the contact section) could be change in the next years be new communication methods and channels but I believe that at this point it will be time to update IDPEF to a new version. Did you (or the community) have any example, what information for field services or technical administration could be necessary which is currently not addressed by IDPEF with could be valuable for incident handling? Thanks for the feedback and the start of discussion. Kind regards. B.-C. Boesch Am 03.02.2015 um 22:21 schrieb Jerome Athias: > after partial second review, I would suggest reviewing "contact" to > align it on "3.10. Contact Class" that you can find here > https://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-10 > > > > 2015-02-03 20:29 GMT+01:00 B.-C. Boesch : >> Hi Jerome, >> >> thanks for your feedback and the post to the STIX community. This is very >> useful to me. >> >> Currently I am not familiar with the STIX specifications but I hope that I >> will be become acquainted with it in the next time. At the first view it >> seems that STIX is focused on signalizing and correlation of events like >> IDMEF. My approach is more a parametrization of IDS entities (Analyzers). I >> keep to make some Data model mappings with STIX. I hope that I will be able >> to spend some time on it next weekend to get familiar with STIX. >> >> I am looking forward to a valuable feedback from the STIX community. >> >> kind regards >> >> Bjoern.-C. Boesch >> >> Am 02.02.2015 um 22:40 schrieb Jerome Athias: >> >>> Hi, >>> >>> very interesting idea and document. >>> Congratulations, and thanks! >>> >>> After a first review, I think I would have quite a lot of comments. >>> Unfortunately I would not have time for proper review before this >>> week-end. >>> Meantime, I would think that there is an opportunity to suggest your >>> work as an extension for STIX, and CybOX >>> http://stix.mitre.org/ >>> Are you familiar with these specifications? >>> I would mainly recommend trying some mappings, etc. I'll be able to help >>> >>> I understand the importance for you to obtain feedbacks, so I should >>> introduce your draft into the STIX community >>> >>> http://making-security-measurable.1364806.n2.nabble.com/STIX-Discussion-List-f7579090.html >>> I hope it's ok for you, and I'm pretty sure you could obtain valuable >>> feedback from there (even if this community is not working with the >>> same requirements as IETF) >>> >>> Best regards >>> >>> 2015-02-02 20:13 GMT+01:00 B.-C. Boesch : >>>> Dear David, >>>> >>>> thanks for your hint to the SACM WG. I have also posted it within the >>>> SACM >>>> community for any comments, feedback, suggestions, notations, hints, >>>> recommendations, etc. but haven´t received any response or feedback to >>>> the >>>> Internet Draft so far. I hope this will change and a lively discussion is >>>> going to come up. >>>> >>>> Kind regards >>>> >>>> B.-C. Boesch >>>> >>>> >>>> Am 02.02.2015 um 18:32 schrieb David Harrington: >>>>> I think similar work is being addressed in the sacm wg. >>>>> >>>>> David Harrington >>>>> ietfdbh@comcast.net >>>>> >>>>> >>>>> >>>>> On Jan 18, 2015, at 3:23 AM, B.-C. Boesch wrote: >>>>> >>>>>> Dear Community, >>>>>> >>>>>> Efficiency of Intrusion Detection Systems (IDS) depends on their >>>>>> configuration and coverage of services. The coverage depends on used >>>>>> IDS >>>>>> with currently vendor-specific configurations. In case of usage of >>>>>> multiple >>>>>> systems the operations could become complex. Individual Communication >>>>>> between management interface and the IDS entities results that current >>>>>> multi-vendor IDS architectures do not interact with each other. They >>>>>> are >>>>>> independent coexistent. >>>>>> >>>>>> The Internet Draft defines data formats and exchange procedures to >>>>>> standardize parametrization information exchange into intrusion >>>>>> detection >>>>>> and response systems from a Manager to an Analyzer. >>>>>> >>>>>> The created Intrusion Detection Parametrization Exchange Format (IDPEF) >>>>>> is intended to be a standard data format to parametrize IDS. The >>>>>> development >>>>>> of this open standardized format and the Intrusion Detection Message >>>>>> Exchange Format (IDMEF) will be enable in combination interoperability >>>>>> among >>>>>> commercial, open source, and research systems, allowing users to >>>>>> mix-and-match the deployment of these systems according to their strong >>>>>> and >>>>>> weak points to obtain an optimal IDS implementation. >>>>>> >>>>>> The most obvious place to implement IDPEF is in the data channel >>>>>> between >>>>>> a Manager and an Analyzer of an IDS within this data channel where the >>>>>> Manager sends the configuration parameters to the Analyzers. But there >>>>>> are >>>>>> other places where the IDPEF can be useful: >>>>>> >>>>>> - Combination of specialized IDS like application-IDS with server-IDS, >>>>>> WLAN-IDS and network-IDS to one functional interacting meta-IDS. >>>>>> >>>>>> - Management of different IDS vendors with one central management >>>>>> interface. >>>>>> >>>>>> - Interaction of different IDS by using IDPEF and IDMEF. >>>>>> >>>>>> - Parametrization backups and restore of parametrized IDS entities. >>>>>> >>>>>> - For a communication between a Manager and a Manager in a multi-stage >>>>>> management architecture. >>>>>> >>>>>> I am happy to invite you to give me feedback, suggestions, notations, >>>>>> hints, recommendations, etc. to improve the Internet Draft. The initial >>>>>> version of the Internet Draft could be found at: >>>>>> >>>>>> http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> B.-C. Boesch >>>>>> >>>>>> _______________________________________________ >>>>>> OPSAWG mailing list >>>>>> OPSAWG@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >> --------------040006060109020703050002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Hi Jerome,

thanks for your feedback and support to align "contact" with "3.10. Contact Class" of RfC 5070 (IODEFv2). I had lots of thoughts about your recommendation and currently I am not sure if this is the best choice. The IODEFv2 is focussed on exchange and handle of incident information by CSIRT humans (maybe with systems support and so it should be parsable). So more than one contact could be helpful to handle the incident. Also it must be flexible to use it for any kind of contact. 

IDMEF (RfC 4765) is focused on signalling of events / incidents within an IDS or its user interface. The IDPEF as Internet Draft is intended to parametrize the Analyzer of an IDS (communication between Manager and Manager or Analyzer). The information handler use the information which is presented to him by the format. 

Focused on the contact class for the field service and the technical contact there will be a single point of contact. The contact node of IDPEF provides multiple contact channels for the field service or a second level service / technical administration where other information like postal address or contact name is located in upper nodes. So This could be the input for IDMEF / IODEF and should predefine to information for this two support contacts of an entity. And there is always one group exclusive responsible for this job. 

IMHO this kind of detailed structured information supports that all information are present. With a machine-machine interaction this could be checked automatically. On the other hand an Analyzer is able to combine or chain these values for IDMEF / IODEF with less efforts, but maybe in any cases not the complete information is needed. 

I am aware that IDPEF and its structure (especially the contact section) could be change in the next years be new communication methods and channels but I believe that at this point it will be time to update IDPEF to a new version. Did you (or the community) have any example, what information for field services or technical administration could be necessary which is currently not addressed by IDPEF with could be valuable for incident handling? 

Thanks for the feedback and the start of discussion. 

Kind regards. 

B.-C. Boesch
Am 03.02.2015 um 22:21 schrieb Jerome Athias:
after partial second review, I would suggest reviewing "contact" to
align it on "3.10. Contact Class" that you can find here
https://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-10



2015-02-03 20:29 GMT+01:00 B.-C. Boesch <bjoernboesch@gmx.net>:

Hi Jerome,

thanks for your feedback and the post to the STIX community. This is very
useful to me.

Currently I am not familiar with the STIX specifications but I hope that I
will be become acquainted with it in the next time. At the first view it
seems that STIX is focused on signalizing and correlation of events like
IDMEF. My approach is more a parametrization of IDS entities (Analyzers). I
keep to make some Data model mappings with STIX. I hope that I will be able
to spend some time on it next weekend to get familiar with STIX.

I am looking forward to a valuable feedback from the STIX community.

kind regards

Bjoern.-C. Boesch

Am 02.02.2015 um 22:40 schrieb Jerome Athias:


Hi,

very interesting idea and document.
Congratulations, and thanks!

After a first review, I think I would have quite a lot of comments.
Unfortunately I would not have time for proper review before this
week-end.
Meantime, I would think that there is an opportunity to suggest your
work as an extension for STIX, and CybOX
http://stix.mitre.org/
Are you familiar with these specifications?
I would mainly recommend trying some mappings, etc. I'll be able to help

I understand the importance for you to obtain feedbacks, so I should
introduce your draft into the STIX community

http://making-security-measurable.1364806.n2.nabble.com/STIX-Discussion-List-f7579090.html
I hope it's ok for you, and I'm pretty sure you could obtain valuable
feedback from there (even if this community is not working with the
same requirements as IETF)

Best regards

2015-02-02 20:13 GMT+01:00 B.-C. Boesch <bjoernboesch@gmx.net>:

Dear David,

thanks for your hint to the SACM WG. I have also posted it within the
SACM
community for any comments, feedback, suggestions, notations, hints,
recommendations, etc. but haven´t  received any response or feedback to
the
Internet Draft so far. I hope this will change and a lively discussion is
going to come up.

Kind regards

B.-C. Boesch


Am 02.02.2015 um 18:32 schrieb David Harrington:

I think similar work is being addressed in the sacm wg.

David Harrington
ietfdbh@comcast.net



On Jan 18, 2015, at 3:23 AM, B.-C. Boesch <bjoernboesch@gmx.net> wrote:


Dear Community,

Efficiency of Intrusion Detection Systems (IDS) depends on their
configuration and coverage of services. The coverage depends on used
IDS
with currently vendor-specific configurations. In case of usage of
multiple
systems the operations could become complex. Individual Communication
between management interface and the IDS entities results that current
multi-vendor IDS architectures do not interact with each other. They
are
independent coexistent.

The Internet Draft defines data formats and exchange procedures to
standardize parametrization information exchange into intrusion
detection
and response systems from a Manager to an Analyzer.

The created Intrusion Detection Parametrization Exchange Format (IDPEF)
is intended to be a standard data format to parametrize IDS. The
development
of this open standardized format and the Intrusion Detection Message
Exchange Format (IDMEF) will be enable in combination interoperability
among
commercial, open source, and research systems, allowing users to
mix-and-match the deployment of these systems according to their strong
and
weak points to obtain an optimal IDS implementation.

The most obvious place to implement IDPEF is in the data channel
between
a Manager and an Analyzer of an IDS within this data channel where the
Manager sends the configuration parameters to the Analyzers. But there
are
other places where the IDPEF can be useful:

- Combination of specialized IDS like application-IDS with server-IDS,
WLAN-IDS and network-IDS to one functional interacting meta-IDS.

- Management of different IDS vendors with one central management
interface.

- Interaction of different IDS by using IDPEF and IDMEF.

- Parametrization backups and restore of parametrized IDS entities.

- For a communication between a Manager and a Manager in a multi-stage
management architecture.

I am happy to invite you to give me feedback, suggestions, notations,
hints, recommendations, etc. to improve the Internet Draft. The initial
version of the Internet Draft could be found at:

http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt

Kind regards,

B.-C. Boesch

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

--------------040006060109020703050002-- From nobody Mon Feb 16 01:48:47 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8107A1A879F; Mon, 16 Feb 2015 01:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKJvqLYjLIzI; Mon, 16 Feb 2015 01:48:43 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EBC1A1A94; Mon, 16 Feb 2015 01:48:42 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1G9mQlW002499 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 10:48:27 +0100 From: Simon Josefsson To: Stephen Farrell References: <54DC00D0.2050900@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150216:saag@ietf.org::Jc2JG4WsjrZNwtiw:BHUR X-Hashcash: 1:22:150216:stephen.farrell@cs.tcd.ie::YPH3Px1gxiJuxrcN:5ofE X-Hashcash: 1:22:150216:kitten@ietf.org::ZDkkZ4ZLrYOkxmVC:NKIr X-Hashcash: 1:22:150216:http-auth@ietf.org::JYW4JhqrwSxgt6go:wIal Date: Mon, 16 Feb 2015 10:48:25 +0100 In-Reply-To: <54DC00D0.2050900@cs.tcd.ie> (Stephen Farrell's message of "Thu, 12 Feb 2015 01:24:32 +0000") Message-ID: <87r3tqqj9y.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:48:44 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > Hiya, > > I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's > needed for some work in http-auth but doesn't quite fit with any > current WG. I plan to start an IETF LC for that shortly, but please > do let me know if there are any issues. Since SCRAM was published, we have learned that the tls-unique channel binding is insecure -- it would be nice if we could combine the SHA256 update with another default channel binding type to resolve that problem. In my view, the problem with SCRAM today isn't primarily its use of SHA1 but it's broken channel binding. A suggested (not even mandated) pbkdf iteration count of at least 4096 is unchanged since RFC 5802 -- I'd really like to see that be significantly higher. Back in 2000 an iteration count of 1000 was recommended as the minimum. Surely computational power has increased more than a factor of four since then. /Simon > This was previously discussed on the kitten WG list, so (with > the WG chairs' permission) I'd ask that you send any comments > there if you've any before I start the IETF LC. (Reply-to is > set to the kitten WG list.) > > Thanks, > S. > > [1] https://tools.ietf.org/html/draft-hansen-scram-sha256 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU4bzpAAoJEIYLf7sy+BGdLJMH/2UVm1Cq+WobKXz4gg4SSPnq mm+Bv1cihrz5FF52mQwKyyjMS1Ww3ZqEl0WPr4aBnBYrV5MM2CR5M9DpO4Bpz1YA sGKFULzk6Y+h246VipIKpw370CTUST/hsB0gMf5fzvnlwPfHEttU1zyL/Ct+2l5/ nRnq93aok7q4BySTaZZn4ZsLzY3Y1cssu5+GrUiSZGnkMILpRpjj1P2hJMyY9A0u d7AQiBomHJZgNf5LJz/epkA7psp0cTW5qdxOqOOV9K4WCamlK3Jwf48qfJdDotJF dOjDuHOno0sCwQyloURg928VuYY7IyW+M093I0A5WcQM009nQtDdBAzIKFp0Te0= =aPqw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 16 02:15:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C281A887F; Mon, 16 Feb 2015 02:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5g2BK_dJm4i; Mon, 16 Feb 2015 02:15:42 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD631A87A9; Mon, 16 Feb 2015 02:15:41 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so40571463obc.1; Mon, 16 Feb 2015 02:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vo+4Lhm2eqkgleBGICOexNOG5aGtpXcl63DV5Rvgeic=; b=eK95kgCRWN4PB30Ggwu9iN+2jHD2scpX8zRn/zdMpy8YXPFhClF/Zeczc8/3EjVqW/ jbuKwYpy9nuqGlB6UB179onkTCJdEYSbRTc/8NxVKR2Bq5+2sYVGsbT94n2AL1q1f+k8 uZAvw8gDtH0qK5hvjSVXdEZjYQ7kalfsdxjw9dDZhF8MA1A+1dBKiH42RgjO0yZ8alMW b+PD3reDG28r9KKWApi1VWH4qORPOmEHJAy0/1yy3g6UcQb3HVrpS7G0nYMxl4VP4PYj 9um7bIySXjgExeillaoP/VbJOeSPJ2arBuVeV42pYgCSsMNLrdoPxe+13kUr7BwykFa3 WhFw== MIME-Version: 1.0 X-Received: by 10.202.94.197 with SMTP id s188mr13992334oib.94.1424081740941; Mon, 16 Feb 2015 02:15:40 -0800 (PST) Received: by 10.202.225.135 with HTTP; Mon, 16 Feb 2015 02:15:40 -0800 (PST) In-Reply-To: <87r3tqqj9y.fsf@latte.josefsson.org> References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> Date: Mon, 16 Feb 2015 21:15:40 +1100 Message-ID: From: Martin Thomson To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:15:44 -0000 On 16 February 2015 at 20:48, Simon Josefsson wrote: > Since SCRAM was published, we have learned that the tls-unique channel > binding is insecure -- it would be nice if we could combine the SHA256 > update with another default channel binding type to resolve that > problem. In my view, the problem with SCRAM today isn't primarily its > use of SHA1 but it's broken channel binding. We have a solution for that: https://tools.ietf.org/html/draft-ietf-tls-session-hash From nobody Mon Feb 16 02:55:21 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A791A0158; Mon, 16 Feb 2015 02:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5iCQbaaK3W7; Mon, 16 Feb 2015 02:55:17 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057FC1A87C6; Mon, 16 Feb 2015 02:55:16 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1GAsxsR009139 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 11:55:00 +0100 Date: Mon, 16 Feb 2015 11:54:57 +0100 From: Simon Josefsson To: Martin Thomson Message-ID: <20150216115457.3c16fdbf@latte.josefsson.org> In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Cj_a0vmV/eSiOCEMBWO5yhM"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:55:18 -0000 --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Mon, 16 Feb 2015 21:15:40 +1100 skrev Re: [saag] AD sponsoring draft-hansen-scram-sha256: > On 16 February 2015 at 20:48, Simon Josefsson > wrote: > > Since SCRAM was published, we have learned that the tls-unique > > channel binding is insecure -- it would be nice if we could combine > > the SHA256 update with another default channel binding type to > > resolve that problem. In my view, the problem with SCRAM today > > isn't primarily its use of SHA1 but it's broken channel binding. >=20 >=20 > We have a solution for that: > https://tools.ietf.org/html/draft-ietf-tls-session-hash Then SCRAM-SHA256 should normatively references that and require that it is implemented for secure use of SCRAM with channel bindings. There are drawbacks with that approach: it is not widely implemented, not published as an RFC that updates earlier TLS versions, and difficult for SCRAM implementers to validate (usually the TLS stack is opaque to the SCRAM implementer). I could live with that though, as a way of pushing the current security problem down from the IETF protocol layer into the implementation layer. Alternatively, use a new channel binding type that use the extended master secret derivation as described by the document above. I could update draft-josefsson-sasl-tls-cb to describe this approach. /Simon --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU4cyCAAoJEIYLf7sy+BGdc9EH/i0+0+gTBOFj5xqU9u8A3JpA exIv/q/HCpm6c4r9PjM9PA6DdqRPr9+bFl/o9h4UPsDw4Fwjny9WetPCUvzf4WFN eCnRQBzwyWVOoyjQftoWiDVFUVI7wJsEgOY1ynyB/br3uoOHtFueLSa9KIOur8aG +mtyBa8067RedRmMV3nRIQCZ/+x8Ui9A0Bwa0gHJ0QlRG7ZzxMP9cIzRvAMaLkrW dBMS3GQ38eTcOFt4lZYUhMPpa2ei7CtKNb6MNLmm1VtzwDhNt9X2V/gUwoFY/U7H krWO1dozYPta14qRrDsY1+wyWxxlWCYaxdaZRGcSC0XTxoW+9WPizXxWVrtKgrs= =85Yc -----END PGP SIGNATURE----- --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM-- From nobody Mon Feb 16 03:10:32 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BE91A876E; Mon, 16 Feb 2015 03:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQuxtGz1mgH9; Mon, 16 Feb 2015 03:10:13 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3044A1A8794; Mon, 16 Feb 2015 03:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424085006; d=isode.com; s=selector; i=@isode.com; bh=H2M622mg5Pj/fBD/ED7nkJsBaHoEU2Zj4EztCeOSPKg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=JFgBTqFpbCCBnUuEJcTlTPsZdm2TS6HzzndlOjyFEgAQ+wH5Z2OOo0kk2N2ggjd6jvNnk3 iEgrUiq1Irg5jhoeqlMJn3L5v70exejMcE3ZCuR6eyR4BF5rOmncLCuzuMvtoF9/0kLv+l CUnJQB/qKRnvprZ+AxJWPEuiyfA7AEs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Feb 2015 11:10:06 +0000 Message-ID: <54E1D009.2050408@isode.com> Date: Mon, 16 Feb 2015 11:10:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Simon Josefsson , Stephen Farrell References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> In-Reply-To: <87r3tqqj9y.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:10:22 -0000 Hi Simon, On 16/02/2015 09:48, Simon Josefsson wrote: [snip] > A suggested (not even mandated) pbkdf iteration count of at least 4096 > is unchanged since RFC 5802 -- I'd really like to see that be > significantly higher. Back in 2000 an iteration count of 1000 was > recommended as the minimum. Surely computational power has increased > more than a factor of four since then. I've heard complains from developers that 4096 with SHA-1 is too high for current Android phones. It would be good to get more information on performance before changing the number. From nobody Mon Feb 16 03:23:12 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7051A8824; Mon, 16 Feb 2015 03:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGA1zhoDn4xb; Mon, 16 Feb 2015 03:23:06 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70AF61A8834; Mon, 16 Feb 2015 03:23:05 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1GBMsio012070 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 12:22:55 +0100 From: Simon Josefsson To: Alexey Melnikov References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150216:kitten@ietf.org::EWdwoo552beHa/0b:WT X-Hashcash: 1:22:150216:http-auth@ietf.org::F8s7r/08HLa4mUxC:29gH X-Hashcash: 1:22:150216:saag@ietf.org::uPGbsf7wXCavTt7U:3dcZ X-Hashcash: 1:22:150216:alexey.melnikov@isode.com::/LkbAKUNDiSHfRjc:2A1c X-Hashcash: 1:22:150216:stephen.farrell@cs.tcd.ie::swRGKVSRaHsx72yf:Bmtq Date: Mon, 16 Feb 2015 12:22:53 +0100 In-Reply-To: <54E1D009.2050408@isode.com> (Alexey Melnikov's message of "Mon, 16 Feb 2015 11:10:01 +0000") Message-ID: <87iof2qewi.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:23:07 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov writes: > Hi Simon, > > On 16/02/2015 09:48, Simon Josefsson wrote: > [snip] >> A suggested (not even mandated) pbkdf iteration count of at least 4096 >> is unchanged since RFC 5802 -- I'd really like to see that be >> significantly higher. Back in 2000 an iteration count of 1000 was >> recommended as the minimum. Surely computational power has increased >> more than a factor of four since then. > I've heard complains from developers that 4096 with SHA-1 is too high > for current Android phones. It would be good to get more information > on performance before changing the number. You will always hear complaints from developers that security features adds computational and other resource costs. When that happens, I prefer asking myself whether the threat model motivates the cost or not. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU4dMNAAoJEIYLf7sy+BGdIAEH+wQRkqNucW+OSk7yZc6dRTyZ 6xHI/xsD8Vg1PjQ12ED7ixYlgEdpcuFOtUt+tPy9hqgDVQcs/Uojmk8HAIcCLhee Z7n3WQnnbBXIGaKYzZeBZWu6dcmBAiQU+S3bldYXoKGrYoH67l1qhInidqgO4hgs dedmZcFj6RxFnFt3vpO4MZvEy2iQKpQJ+179spNhbMDKa0obgofdwhcWKcOkz5GI G3IUHocYVjJZmrPJp2D5jlsh9y59VoV0sWH5/jP++qgyC81r9bj42fIkl/oQbjBz OrPQAOI9j8ZE4mRMjs37tFO//l4N8l+ixyDpAhWRfYN6NPcPgPD9bgoWfMc2bDo= =kxUe -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 16 09:30:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5171A882C for ; Mon, 16 Feb 2015 03:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsxE7kAiC6ih for ; Mon, 16 Feb 2015 03:21:34 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E33D1A8825 for ; Mon, 16 Feb 2015 03:21:34 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so41052506obc.1 for ; Mon, 16 Feb 2015 03:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wgyXFE5xwyGIhKJiS4fp1H4E3c6EICG4Fgz5lzKMPAw=; b=JjR9sU3mxf3nYJQhDweL0DazRsbcWKsnw0pvph2t8LxRdA7WCfMk9kw+3JMz+gIxZa mE8/usiyrpoR4+fc9uMxMgvQdg2TS8BU8SBoD2OmDp+/prmgoOUva3tNjPpTHoejHFPL Q2OfGOg/UpYQ2wt8/vD2Zi/CE8zevNQUHLT3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wgyXFE5xwyGIhKJiS4fp1H4E3c6EICG4Fgz5lzKMPAw=; b=nKU865LZcWgwNbhDE/BtBMMS5iCReBORtbkBKi/wsazuc8qqrumr3ZBznstY3iD0W4 lH9bJfUUZz1GQMUNMMoSdDqySJp4HLcTc735UgeADt5LGZcM3hsu+U5nbDEPhPPFBOY3 yopS4lJI4jQi/9c6983XNgidlJnyCGwQQzSiBoQRnLbsl3cR7XrDh2AVfutsGTSzZAsa ZHTGGftUWgpu2Mp6tbJF+K7npH/yLBk/5HtG6LIfx0vYQeoqwC8je+zNJr+USkkVseg9 l5fg6YPeWixS93R0cpbWiwHRMXE8fBS954gYrHneiAbfiJQWVkyT1i3x3BwI671qcYsx sGRg== X-Gm-Message-State: ALoCoQn12eGA8+cPskfvPIFhOKbAU8KLlDgk8We7JQDjMEBqRP2wPzWM1rHlRFO75/MdC17S4avw MIME-Version: 1.0 X-Received: by 10.202.52.215 with SMTP id b206mr14131825oia.31.1424085693831; Mon, 16 Feb 2015 03:21:33 -0800 (PST) Received: by 10.60.77.71 with HTTP; Mon, 16 Feb 2015 03:21:33 -0800 (PST) Received: by 10.60.77.71 with HTTP; Mon, 16 Feb 2015 03:21:33 -0800 (PST) In-Reply-To: <54E1D009.2050408@isode.com> References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> Date: Mon, 16 Feb 2015 11:21:33 +0000 Message-ID: From: Dave Cridland To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a113cd412e936aa050f32c9c1 Archived-At: X-Mailman-Approved-At: Mon, 16 Feb 2015 09:30:08 -0800 Cc: kitten@ietf.org, Simon Josefsson , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:21:36 -0000 --001a113cd412e936aa050f32c9c1 Content-Type: text/plain; charset=UTF-8 On 16 Feb 2015 11:10, "Alexey Melnikov" wrote: > > Hi Simon, > > On 16/02/2015 09:48, Simon Josefsson wrote: > [snip] > >> A suggested (not even mandated) pbkdf iteration count of at least 4096 >> is unchanged since RFC 5802 -- I'd really like to see that be >> significantly higher. Back in 2000 an iteration count of 1000 was >> recommended as the minimum. Surely computational power has increased >> more than a factor of four since then. > > I've heard complains from developers that 4096 with SHA-1 is too high for current Android phones. It would be good to get more information on performance before changing the number. > Worth asking in the XSF, there's likely to be implementation experience from the Android client devs there. However, clients need only do the iterations once, if the salt is stable, at least in principle. > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --001a113cd412e936aa050f32c9c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Feb 2015 11:10, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:
>
> Hi Simon,
>
> On 16/02/2015 09:48, Simon Josefsson wrote:
> =C2=A0[snip]
>
>> A suggested (not even mandated) pbkdf iteration count of at least = 4096
>> is unchanged since RFC 5802 -- I'd really like to see that be<= br> >> significantly higher.=C2=A0 Back in 2000 an iteration count of 100= 0 was
>> recommended as the minimum.=C2=A0 Surely computational power has i= ncreased
>> more than a factor of four since then.
>
> I've heard complains from developers that 4096 with SHA-1 is too h= igh for current Android phones. It would be good to get more information on= performance before changing the number.
>

Worth asking in the XSF, there's likely to be implementa= tion experience from the Android client devs there.

However, clients need only do the iterations once, if the sa= lt is stable, at least in principle.

>
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.i= etf.org/mailman/listinfo/kitten

--001a113cd412e936aa050f32c9c1-- From nobody Wed Feb 18 09:51:19 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0A71A1A9A for ; Wed, 18 Feb 2015 04:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9js0-O6TsrRI for ; Wed, 18 Feb 2015 04:58:27 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918751A1AB6 for ; Wed, 18 Feb 2015 04:58:27 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id l6so642577qcy.2 for ; Wed, 18 Feb 2015 04:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qZHGLYKv3Qd4bSALEINcFelyyLSeIqoiShDEAuS/P+w=; b=ydE2EB7HA3zwlQzqPnEGTvdRLu2ohiZ6ARWMBo9Ma/BjI2Bx48Md2XihVVjlgmh+ag eVieU8qIWrwDK9jWkm5FbSi4t1Q+1CLPzBV88gTgIHcTszQgz0/RW/mGowX59hgTNqGc YwrXMGK8D93l/2iqc2T9x0QaU+3fhZH/c4+tA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qZHGLYKv3Qd4bSALEINcFelyyLSeIqoiShDEAuS/P+w=; b=CmvIEPB8OB8pbcVZTYEphiVWybj180+YGasEjfeC7IzudXN/60rhLZkb+e8BADL79z LrbOasGcexVKY+/Nst/z1ml34uaIh3hOCUXSa2CnKSzhSzMHbHVqQxOZr6Nz4TiHRHv5 Lg6c/ZuG8jM2fwBT2nPFhFKHMJ2cvisSRAVC0YRaQVkgIquOeS+h1CfpO45q5JRc5jlS wuvnezwKLhUVpszhUREZ9HgsPmdWKFjVVmR0swom8ND+a0A2Vq3PRYX7h1cZg4I8p0qR REO0umx0xVDGAv/8TakBUYnwGieV2gt+jeiefO3E5qV3MgCo0v2meoUHbzfvGXibZQc+ WTxg== X-Gm-Message-State: ALoCoQlH/xHePHJStNGzSEEAvfoDs9ER8cYrk0q5YkdwY4RE6fg0wGFUxTJCBZzYytlnjc5s6te8 X-Received: by 10.229.216.130 with SMTP id hi2mr657282qcb.4.1424264306770; Wed, 18 Feb 2015 04:58:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.22.51 with HTTP; Wed, 18 Feb 2015 04:57:46 -0800 (PST) X-Originating-IP: [75.117.16.85] In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> From: Sam Whited Date: Wed, 18 Feb 2015 07:57:46 -0500 Message-ID: To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 18 Feb 2015 09:51:18 -0800 Cc: kitten@ietf.org, "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 12:58:32 -0000 On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland wrote: > Worth asking in the XSF, there's likely to be implementation experience f= rom > the Android client devs there. I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't remember actual numbers off the top of my head, I can definitely tell you that there is a noticable delay with a 4096 iteration count (probably a little over half a second) on my HTC m7 (which is fairly beefy as far as phones go). HOWEVER=E2=80=94 > However, clients need only do the iterations once, if the salt is stable,= at > least in principle. =E2=80=94since we then store the session information in an LRU Cache in memory, it's only slow when you first login. I've thought about moving the session info to the database as well to make it even more persistant, but decided it wasn't enough of a problem to bother polluting the database. Best, Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Thu Feb 19 09:04:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AE61A9168 for ; Thu, 19 Feb 2015 09:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCqQf7Ffr7k2 for ; Thu, 19 Feb 2015 09:04:01 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20F91A89D3 for ; Thu, 19 Feb 2015 09:04:00 -0800 (PST) Received: by labgf13 with SMTP id gf13so833609lab.9 for ; Thu, 19 Feb 2015 09:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Wq5JEtOsZ9KZlwZ2HYerVr4Jk+LlWePLoj3DXCMo/Lc=; b=Nvb6rl6oSQmIVBZOxqJ/FOZ9IpETPsdFyCNurQ2GzpL7wPVs1KhCjup5Xhe7pu1e+Y znazl20srnwjd9YiFAQuI+3+zYkwajScEMEGVtUNfBGrTyWezq7tBDSNjk0fNhCelqY4 0VW8PWVRMnFKEEfnlStZzK+6uH8yr8RtNVaduvwDoU8rEgpL6Q9g2ez9LMEJf0LT3f9O fGniGt8fHT7NPUD/BBviH7eeL7YDnz7YfapKj9Nb9WYmhsQdiN8wKhOUw2Cm9WRIelnC Wtx4Is+O9MHaxY0XCkdPxiQ41KNFLQBw1PTmvtSY2eGmbQWu4BNya196j/GuI3xiBF0S sB5Q== MIME-Version: 1.0 X-Received: by 10.152.120.8 with SMTP id ky8mr4673701lab.118.1424365438932; Thu, 19 Feb 2015 09:03:58 -0800 (PST) Sender: hallam@gmail.com Received: by 10.113.3.165 with HTTP; Thu, 19 Feb 2015 09:03:58 -0800 (PST) Date: Thu, 19 Feb 2015 12:03:58 -0500 X-Google-Sender-Auth: 3-fE8TDFjKGEUV9I75B9JYviv9o Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=089e0122aef8049cec050f73ecf6 Archived-At: Subject: [saag] A URI for cryptographic keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:04:03 -0000 --089e0122aef8049cec050f73ecf6 Content-Type: text/plain; charset=UTF-8 This has come up a few times in the past. This time though I would really like us to get something done. In a nutshell, it would be really useful if there was a type of URI that could be simply cut and pasted that would specify either: * A user account and a means of authenticating a credential that authenticates the user of that account. * An Internet service and means of authenticating a credential that authenticates that service. So let us say that we are working on ACME or DPRIV and we are looking for a way to tell the client or device (or whatever) that it should use service X and authenticate it with key Y. Forget for a minute the user interface details of how we arrive at this point. At some point we are going to come down to a DNS name and some means of authenticating the server key on the client side and a user account and a means of authenticating the user on the server side. What I would like is a URI form that would allow this type of relationship to be described: user:alice@example.com:AwRhsxbsSU8qI-1vqfVavrKQ service:example.com:acme.tcp:Ae_9fezf3UABuCE6llMYdDwA Think of these as the 'thin waist' for authentication mechanisms. No matter what the actual authentication mechanism is or how these credentials were established, I can provide a description of the authentication credential in this form and then use it to verify the actual credential against. SAML, PKIX, OpenID, OAUTH, Kerberos, everything can be expressed in one form. user:@: service::: These URI forms are the sort of thing we might put in a configuration file or the windows registry or any other configuration file. They are not something I think we would want to thrust in front of the user's face. But having the ability to handle them as text strings will be very useful on occasion. Particularly if we are configuring an embedded device via a USB cable or such. The authenticator part can be either direct or indirect. A direct authenticator being the cryptographic key itself and an indirect authenticator being a means to authenticate the key. The cryptographic keys themselves may be either a public key or a kerberos like ticket. Which type of authenticator we wanted to make use of would depend on what layer we are in the crypto-stack. At the very top layer the authenticator would probably be a SHA512-256 or SHA512-128 digest of the root of trust in a PKI. If I am configuring an ACME client to connect to the Comodo CA for certificate issue, I probably want the authenticator to be the root of trust for the Comodo CA, i.e. a digest of the keyinfo block of some Comodo root cert. At the very bottom crypto layer we only use symmetric keys. So the authenticator might be a Kerberos ticket or the like. Obviously this is not the type of credential you would usually want to have lying around in a static config file. In between we would probably have use for using a public key as the authenticator. Or at least will do once we get a ~256 bit ECC algorithm agreed. I would not want to cut and paste raw RSA keys but lots of people are already doing just that for Curve25519. --089e0122aef8049cec050f73ecf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This has come up a few times in the past. This time though= I would really like us to get something done.

In a nuts= hell, it would be really useful if there was a type of URI that could be si= mply cut and pasted that would specify either:

* A= user account and a means of authenticating a credential that authenticates= the user of that account.

* An Internet service a= nd means of authenticating a credential that authenticates that service.


So let us say that we are working on = ACME or DPRIV and we are looking for a way to tell the client or device (or= whatever) that it should use service X and authenticate it with key Y.

Forget for a minute the user interface details of how= we arrive at this point. At some point we are going to come down to a DNS = name and some means of authenticating the server key on the client side and= a user account and a means of authenticating the user on the server side.<= /div>


What I would like is a URI form tha= t would allow this type of relationship to be described:

user:alice@example.com:AwRhsxbsSU8qI-1vqfVavrKQ
service:ex= ample.com:acme.tcp:Ae_9fezf3UABuCE6llMYdDwA


Think of these as the 'thin waist' for authentication mech= anisms. No matter what the actual authentication mechanism is or how these = credentials were established, I can provide a description of the authentica= tion credential in this form and then use it to verify the actual credentia= l against. SAML, PKIX, OpenID, OAUTH, Kerberos, everything can be expressed= in one form.

user:<account>@<dns-name>= ;:<authenticator>
service:<dns-name>:<service-pref= ix>:<authenticator>

These URI forms a= re the sort of thing we might put in a configuration file or the windows re= gistry or any other configuration file. They are not something I think we w= ould want to thrust in front of the user's face. But having the ability= to handle them as text strings will be very useful on occasion. Particular= ly if we are configuring an embedded device via a USB cable or such.=C2=A0<= /div>


The authenticator part can be eithe= r direct or indirect. A direct authenticator being the cryptographic key it= self and an indirect authenticator being a means to authenticate the key.

The cryptographic keys themselves may be either a p= ublic key or a kerberos like ticket.


Which type of authenticator we wanted to make use of would depend on what= layer we are in the crypto-stack.=C2=A0

At the ve= ry top layer the authenticator would probably be a SHA512-256 or SHA512-128= digest of the root of trust in a PKI. If I am configuring an ACME client t= o connect to the Comodo CA for certificate issue, I probably want the authe= nticator to be the root of trust for the Comodo CA, i.e. a digest of the ke= yinfo block of some Comodo root cert.

At the very = bottom crypto layer we only use symmetric keys. So the authenticator might = be a Kerberos ticket or the like. Obviously this is not the type of credent= ial you would usually want to have lying around in a static config file.

In between we would probably have use for using a pu= blic key as the authenticator. Or at least will do once we get a ~256 bit E= CC algorithm agreed. I would not want to cut and paste raw RSA keys but lot= s of people are already doing just that for Curve25519.





--089e0122aef8049cec050f73ecf6-- From nobody Thu Feb 19 09:17:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E37D1A0469 for ; Thu, 19 Feb 2015 09:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28YnIqKzUZpS for ; Thu, 19 Feb 2015 09:17:14 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454461A040B for ; Thu, 19 Feb 2015 09:17:14 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id e89so7702192qgf.9 for ; Thu, 19 Feb 2015 09:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xZ9bL+YBQePKJgoKEJsaiuao+Q2aVFu0S0MAytCmUzQ=; b=aZDN9nuE0FtE6x2rsYnv/PPmsY0AS+sJNMxeBYhDxWj3FDYGPRgj1ggjVj/IABtsUd i0TNECMPjanQXu/8iVWoUiaPJ0PI45aJu0jy9BIOFU8L7i7S2LiJN0Y+f5MqWT1q3uyf U2CX6AQmG3E+o5G3PkZgVjgacjyuUguvlpUZizioS2PqxEX40oq1QvIYPLauYcCW7Fhp o2WkdO84mSEikj8e3imV2H8W9H8PLpDbeHe+jx49AYn6ZCDQ68oO6D/JUg40m0YraKqD q0K/1OThWgyfj0FR93EgOCpWC33bKFNs4UcM77HRymXx5WbVyRrQnBReJ+Lpl6KNIc5R kDwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xZ9bL+YBQePKJgoKEJsaiuao+Q2aVFu0S0MAytCmUzQ=; b=K3Bbi2ZocqknpTt7MYfQJYspAol7Ux7PhaFA0NI1IV90GSp6z/HR5hLu1wv7CaY2mx mSXYhb1ImcvNUM6qfLmNixClg3Ik5MipJVf2VhuF3u2BMm1HHV0mqYchhskgxlE6KFkc FFNaumbdxL5h2OHVSY7M+29fg2Bx5BJPZJiObsTpUTzYRQdxJyzZdzfJKdxzxsU1omvT otlN8/nsrOTTbQly6KCwny2oEQGfqGua7E8eIxxThu7siXg4KXvEY93gk8SSn7l9zC8V rcW9u7pKGzLwals4Hcg8n7MpO0soC8P3EdE7vWdnK4+2lt8POPUe80m11DftvuGGNAYk picA== X-Gm-Message-State: ALoCoQlU0pJ3BbcNg5E4j9fetF1eBJ7+lxaIYLrzHruqMdIFrQ1bW/ZGv5up/rlWOWWVhaGqg5GF MIME-Version: 1.0 X-Received: by 10.140.92.33 with SMTP id a30mr13636014qge.30.1424366233272; Thu, 19 Feb 2015 09:17:13 -0800 (PST) Received: by 10.229.224.6 with HTTP; Thu, 19 Feb 2015 09:17:13 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2015 17:17:13 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A URI for cryptographic keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:17:16 -0000 Are these not YURLs? http://www.waterken.com/dev/YURL/. On 19 February 2015 at 17:03, Phillip Hallam-Baker wrote: > This has come up a few times in the past. This time though I would really > like us to get something done. > > In a nutshell, it would be really useful if there was a type of URI that > could be simply cut and pasted that would specify either: > > * A user account and a means of authenticating a credential that > authenticates the user of that account. > > * An Internet service and means of authenticating a credential that > authenticates that service. > > > So let us say that we are working on ACME or DPRIV and we are looking for a > way to tell the client or device (or whatever) that it should use service X > and authenticate it with key Y. > > Forget for a minute the user interface details of how we arrive at this > point. At some point we are going to come down to a DNS name and some means > of authenticating the server key on the client side and a user account and a > means of authenticating the user on the server side. > > > What I would like is a URI form that would allow this type of relationship > to be described: > > user:alice@example.com:AwRhsxbsSU8qI-1vqfVavrKQ > service:example.com:acme.tcp:Ae_9fezf3UABuCE6llMYdDwA > > > Think of these as the 'thin waist' for authentication mechanisms. No matter > what the actual authentication mechanism is or how these credentials were > established, I can provide a description of the authentication credential in > this form and then use it to verify the actual credential against. SAML, > PKIX, OpenID, OAUTH, Kerberos, everything can be expressed in one form. > > user:@: > service::: > > These URI forms are the sort of thing we might put in a configuration file > or the windows registry or any other configuration file. They are not > something I think we would want to thrust in front of the user's face. But > having the ability to handle them as text strings will be very useful on > occasion. Particularly if we are configuring an embedded device via a USB > cable or such. > > > The authenticator part can be either direct or indirect. A direct > authenticator being the cryptographic key itself and an indirect > authenticator being a means to authenticate the key. > > The cryptographic keys themselves may be either a public key or a kerberos > like ticket. > > > Which type of authenticator we wanted to make use of would depend on what > layer we are in the crypto-stack. > > At the very top layer the authenticator would probably be a SHA512-256 or > SHA512-128 digest of the root of trust in a PKI. If I am configuring an ACME > client to connect to the Comodo CA for certificate issue, I probably want > the authenticator to be the root of trust for the Comodo CA, i.e. a digest > of the keyinfo block of some Comodo root cert. > > At the very bottom crypto layer we only use symmetric keys. So the > authenticator might be a Kerberos ticket or the like. Obviously this is not > the type of credential you would usually want to have lying around in a > static config file. > > In between we would probably have use for using a public key as the > authenticator. Or at least will do once we get a ~256 bit ECC algorithm > agreed. I would not want to cut and paste raw RSA keys but lots of people > are already doing just that for Curve25519. > > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Thu Feb 19 10:14:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D361A0019 for ; Thu, 19 Feb 2015 10:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OSp5Ru1hBeY for ; Thu, 19 Feb 2015 10:14:39 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403A71A7033 for ; Thu, 19 Feb 2015 10:14:39 -0800 (PST) Received: by labms9 with SMTP id ms9so1262593lab.10 for ; Thu, 19 Feb 2015 10:14:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PwR/y9dM5Ip/s1y0v4SmKeLCzJ65U2Tb42WgNhu2Rhg=; b=P7sdUSzL0adFXJn7/PqNh8XoKveXZcPlYdutQb6jdiwSw8woJI2f/RnyepEQkVeKWM oceWDvmHFED8D7+pLIUgx6GG55XMK03UvSfTmjvU3orPcoEq3lTg4TaAlOCw3ho6Mfcs I5ozhSnY9hLET7W2Vpx5DKzNEfj7BigseDG+y9FcG/aVu4DOUwg36XtMN7XkKaOfBIzB xsjwKV5Q0j+TX4HSNttagQ7sxbZUIs9PKNxh+TiAqcb3VmnSLMUw+Xr1MB2DJg67Zv+C sQEioRYzmjnJFoiX3Q0gqRGOpkXNOmtje1i3ePb8hLkdV4UUgeT6CUyibPf2npqUR3wb 8Pag== X-Gm-Message-State: ALoCoQm1QgyXIk8B0dnK5A3hYVxIeS7pJTXlx/VhtxmlInTyTiuowLa0ElOswrW/kkkZtLpANvfC X-Received: by 10.152.37.106 with SMTP id x10mr5134380laj.52.1424369677545; Thu, 19 Feb 2015 10:14:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.139.36 with HTTP; Thu, 19 Feb 2015 10:13:57 -0800 (PST) X-Originating-IP: [50.5.83.246] In-Reply-To: References: From: "Scott R. Corzine" Date: Thu, 19 Feb 2015 13:13:57 -0500 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A URI for cryptographic keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 18:14:42 -0000 On Thu, Feb 19, 2015 at 12:03 PM, Phillip Hallam-Baker wrote: > Think of these as the 'thin waist' for authentication mechanisms. No matter > what the actual authentication mechanism is or how these credentials were > established, I can provide a description of the authentication credential in > this form and then use it to verify the actual credential against. SAML, > PKIX, OpenID, OAUTH, Kerberos, everything can be expressed in one form. > > user:@: > service::: If successful there are going to be users who have multiple keys with the same @ or :. These will have been created for different purposes, need user-designated tags for special needs (e.g. designate destination or for prod/dev/test), dates or numbers for users to be able to rotate/regenerate their keys, etc. In many cases users will primarily depend on the information in the URI for selection.. So adding a simple field that can contain what's important to the user should work. We should not depend on the users (either creators or consumers) maintaining this information external to the keys (filenames, formatted documents, databases). Many people will have them scattered around in various files and mail messages. Existing URIs in flat configuration files usually won't have anything beyond the URI. I'm just suggesting a simple external field, tag or label. It doesn't have to be signed. There is utility in letting this tag information be changed by the user of the URI. If each person can only distinguish to the account@dns-name level then they will tend to only use one key for all purposes and as long as they can. Anything else will cause too much headache. For example, I do this with my ssh keys to distinguish between different keys for different destinations/purposes and track when the key was generated. Encoding as an email address I can use something like this "scott+github-2015-01-01@ties.org". It's kludgy but my ssh keys are maintainable, identifiable, and updatable. I can use different keys for appropriate purposes and know where they're generated/stored. I'm not necessarily saying we should use the + syntax for such purposes. Just a simple user field which can be separated into different uses and have new information added to it. These URIs will get separated from metadata, jumbled around and need to be self-identifying. -Scott- On Thu, Feb 19, 2015 at 12:03 PM, Phillip Hallam-Baker wrote: > This has come up a few times in the past. This time though I would really > like us to get something done. > > In a nutshell, it would be really useful if there was a type of URI that > could be simply cut and pasted that would specify either: > > * A user account and a means of authenticating a credential that > authenticates the user of that account. > > * An Internet service and means of authenticating a credential that > authenticates that service. > > > So let us say that we are working on ACME or DPRIV and we are looking for a > way to tell the client or device (or whatever) that it should use service X > and authenticate it with key Y. > > Forget for a minute the user interface details of how we arrive at this > point. At some point we are going to come down to a DNS name and some means > of authenticating the server key on the client side and a user account and a > means of authenticating the user on the server side. > > > What I would like is a URI form that would allow this type of relationship > to be described: > > user:alice@example.com:AwRhsxbsSU8qI-1vqfVavrKQ > service:example.com:acme.tcp:Ae_9fezf3UABuCE6llMYdDwA > > > Think of these as the 'thin waist' for authentication mechanisms. No matter > what the actual authentication mechanism is or how these credentials were > established, I can provide a description of the authentication credential in > this form and then use it to verify the actual credential against. SAML, > PKIX, OpenID, OAUTH, Kerberos, everything can be expressed in one form. > > user:@: > service::: > > These URI forms are the sort of thing we might put in a configuration file > or the windows registry or any other configuration file. They are not > something I think we would want to thrust in front of the user's face. But > having the ability to handle them as text strings will be very useful on > occasion. Particularly if we are configuring an embedded device via a USB > cable or such. > > > The authenticator part can be either direct or indirect. A direct > authenticator being the cryptographic key itself and an indirect > authenticator being a means to authenticate the key. > > The cryptographic keys themselves may be either a public key or a kerberos > like ticket. > > > Which type of authenticator we wanted to make use of would depend on what > layer we are in the crypto-stack. > > At the very top layer the authenticator would probably be a SHA512-256 or > SHA512-128 digest of the root of trust in a PKI. If I am configuring an ACME > client to connect to the Comodo CA for certificate issue, I probably want > the authenticator to be the root of trust for the Comodo CA, i.e. a digest > of the keyinfo block of some Comodo root cert. > > At the very bottom crypto layer we only use symmetric keys. So the > authenticator might be a Kerberos ticket or the like. Obviously this is not > the type of credential you would usually want to have lying around in a > static config file. > > In between we would probably have use for using a public key as the > authenticator. Or at least will do once we get a ~256 bit ECC algorithm > agreed. I would not want to cut and paste raw RSA keys but lots of people > are already doing just that for Curve25519. > > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Thu Feb 19 10:47:26 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D811A1B9A for ; Thu, 19 Feb 2015 10:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue3amk-uALbu for ; Thu, 19 Feb 2015 10:47:24 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CAF1A0158 for ; Thu, 19 Feb 2015 10:47:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1CA8820614; Thu, 19 Feb 2015 13:46:32 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK7MOOm6-BaM; Thu, 19 Feb 2015 13:46:30 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (gain1-180.nortex.net [63.160.158.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 19 Feb 2015 13:46:29 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E3750807C9; Thu, 19 Feb 2015 13:46:43 -0500 (EST) From: Sam Hartman To: Phillip Hallam-Baker References: Date: Thu, 19 Feb 2015 13:46:43 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 19 Feb 2015 12:03:58 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A URI for cryptographic keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 18:47:25 -0000 >>>>> "Phillip" == Phillip Hallam-Baker writes: Hi. I spent a few minutes trying to understand what you're proposing, and completely failed. I'd consider myself fairly versed in authentication and if I can't follow it at all, I'm probably not the only one. So, I'd appreciate it if you would be willing to try and explain this a bit better. Also, I'm not really sure that the authentication technologies I'm familiar with work the way you claim they do. Please consider the following: Phillip> Forget for a minute the user interface details of how we Phillip> arrive at this point. At some point we are going to come Phillip> down to a DNS name and some means of authenticating the Phillip> server key on the client side and a user account and a Phillip> means of authenticating the user on the server side. What Phillip> I would like is a URI form that would allow this type of Phillip> relationship to be described: Fundamentally it's not obvious to me that the above paragraph applies to Kerberos, SAML and I'm unclear about OAUTH. I understand you claimed that it does apply to those technologies, but I consider myself rather familiar with Kerberos and fairly familiar with SAML, and I just don't see it. take Kerberos for example: * the server and client don't have separate keys * The assumptions you're making about DNS don't apply to Kerberos. For SAML: * Depending on the profile SAML may not have a lot to say about validating the server. * SAML naming has very little to do with DNS especially for the names of subjects. So, please take a step back--a lot of steps back and explain what you're trying to do at least well enough that those of us who have spent a fair bit of time working with the technologies you're discussing can: 1) understand 2) agree that for technologies we're familiar with you're capturing the aspects of our technology we consider important. Thanks, --Sam From nobody Thu Feb 19 11:50:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C521A87C7 for ; Thu, 19 Feb 2015 11:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGnY4zLUCjzs for ; Thu, 19 Feb 2015 11:49:57 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316C51A0053 for ; Thu, 19 Feb 2015 11:49:57 -0800 (PST) Received: by labhs14 with SMTP id hs14so1914175lab.1 for ; Thu, 19 Feb 2015 11:49:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cGBbtVBPd+vpsl84XyfdAXQLh1zOZJAlXV+oQr9ru+k=; b=DbDXkjSO6S+gHL0ChaleU3r4uR/j6Jmg5nKVkQWvvQEtVrf031DGuh2MGD702v0KFM IBvxJ60itha6Z7kFpIjcA7Hv1ideY7JEvCsKAh9ae0HzAmWem+E7uLyyQJJ+qMH/am9+ DYA/5yZXLnOfCDiJ0gLocVBwrEYs5+X+lKrVMdveBhpYg4jxs3ZXiSNzBhRVPG/YPFW7 UB2tT8vlB3dZ86bsTXm5f90hx+Jtj3KHFe4y8NUt5YyiFNVeNPm5qkt4x3E+1txpgAF2 UsLcept3qKKdH5jhDdO0ES05Uh5cDXSR7Y3uhCCbd/whmIORuqFvIQ49DK0oh9tffBG0 5Y3g== X-Gm-Message-State: ALoCoQmnkTS/+R0sEOgB/OyUVpywL8fAH7feqCbAySkUKU30U8XQIlsGpsSZUY2sMxAhGkd5ghp4 X-Received: by 10.112.12.228 with SMTP id b4mr5337005lbc.83.1424375395568; Thu, 19 Feb 2015 11:49:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.139.36 with HTTP; Thu, 19 Feb 2015 11:49:15 -0800 (PST) X-Originating-IP: [50.5.83.246] In-Reply-To: References: From: "Scott R. Corzine" Date: Thu, 19 Feb 2015 14:49:15 -0500 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A URI for cryptographic keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:49:59 -0000 On Thu, Feb 19, 2015 at 12:17 PM, Ben Laurie wrote: > Are these not YURLs? http://www.waterken.com/dev/YURL/. >From a quick read of the YURL site and my understanding of this proposal I would say they are very different things: This proposal simply appears to define URIs which can pair an user account or a service with an authenticator, a complete key or an authenticator/id for an external key. There's a lot of discussion of protocols and different authentication methods but I read that as discussion of how they could interact not a proposal to replace of change any of them. YURL is complex. It appears to purportedly simultaneously eliminate or reduce reliance on the PKI and DNS (both of which are strongly criticized along with the "global namespace"). It involves URLs containing: *mandatory pre-shared* SHA-1 hash of a X.509 public key as the primary resource id, multiple network connections, a list of "hints" - IP addresses ("not discouraged")/DNS names at least one of which must exist, intentional use of HTTP redirects as a location service, TLS/1.0 (required) with reduced PKI use, all of the preceding repeated until success is achieved or the hints run out. Then, finally, a normal HTTP dialogue for /url-path. That's a single request. -Scott- From nobody Thu Feb 19 11:57:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB591A011E for ; Thu, 19 Feb 2015 11:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Luf7e7Wz4QGn for ; Thu, 19 Feb 2015 11:57:22 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A71A0072 for ; Thu, 19 Feb 2015 11:57:22 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id DBF4E35005B for ; Thu, 19 Feb 2015 11:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=LwcddZ/O7i17/2t/EjJ0 Bfuny1I=; b=HaljpGcE5If7QzfZNuwAbUUb3rAuhaU1bfWicKcnZSSR5mrznl/D hq3PAHJSzmixBhERub5xo5EfJMIRttl0sW7DrsPmzV+MTV9z2k3IQsz7X24jkSyr bPB7FLr9hSR+u4fVctO60faELHaPrq9G6Fv7ePeFCWdZqajAmuLnXg8= Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id CA7C2350058 for ; Thu, 19 Feb 2015 11:57:21 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id l13so46672283iga.5 for ; Thu, 19 Feb 2015 11:57:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.36.104 with SMTP id p8mr9822265igj.16.1424375840857; Thu, 19 Feb 2015 11:57:20 -0800 (PST) Received: by 10.64.130.66 with HTTP; Thu, 19 Feb 2015 11:57:20 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2015 13:57:20 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A URI for cryptographic keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:57:23 -0000 Have you seen PKCS#11 URIs? (Not that that's the right answer for you, but if the credentials needed to use are buried in a token that must be accessed via PKCS#11, then PKCS#11 URIs become part of the answer. Particularly since PKCS#11 URIs allow you to specify a provider, in case that a platform default doesn't know how to access the credentials, and so on.) Nico -- From nobody Mon Feb 23 17:30:47 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183621A066B for ; Mon, 23 Feb 2015 17:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Y8HylBK_Cw for ; Mon, 23 Feb 2015 17:30:43 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B31C1A01F2 for ; Mon, 23 Feb 2015 17:30:43 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t1O1PEJZ017499; Mon, 23 Feb 2015 17:30:41 -0800 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1smmx8q1vp-50 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Feb 2015 17:30:40 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([::1]) with mapi; Mon, 23 Feb 2015 17:30:34 -0800 From: Paul Lambert To: Phillip Hallam-Baker , "saag@ietf.org" Date: Mon, 23 Feb 2015 17:30:33 -0800 Thread-Topic: [saag] A URI for cryptographic keys Thread-Index: AdBMZhVQhhcL5MQgRuiZdes1sgoAgwDaoJYw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D020E27DBD8A@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D020E27DBD8ASCVEXCH2marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-23_03:2015-02-23,2015-02-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502240011 Archived-At: Subject: Re: [saag] A URI for cryptographic keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 01:30:46 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D020E27DBD8ASCVEXCH2marve_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaW50ZXJlc3RlZCBpbiBjcnlwdG9ncmFwaHkgaW4gVVJJcyBvciBZVVJMcywgYnV0IGFt IHZlcnkgY29uZnVzZWQgYnkgIHRoZSBwcm9wb3NhbCBiZWxvdy4NCg0KUGVyaGFwcyBhIG1vcmUg c3VjY2luY3QgdXNlIGNhc2Ugd291bGQgaGVscC4NCg0KSeKAmW0gd29ya2luZyBub3cgb24gdHJ5 aW5nIHRvIGJpbmQgYSDigJhzZXJ2aWNl4oCZLCDigJhjb21tdW5pY2F0aW9uIGNoYW5uZWzigJkg YW5kIGEgZXBoZW1lcmFsIHB1YmxpYyBrZXkgYXMgYSBZVVJMLWlzaCBpbnRyb2R1Y3Rpb24uICBU aGlzIHdvdWxkIGJlIGluIFFSIGNvZGVzIHRvIHNlY3VyZWx5IGNvbm5lY3QgdG8gYSByZWxhdGVk IHdpcmVsZXNzIFAyUCBzZXJ2aWNlLiAgVGhlIGNoYXJhY3RlciBlbmNvZGluZyBpbiBhIFFSLUNv ZGUgbWlnaHQgYmVuZWZpdCBmcm9tIHRoZSB1c2Ugb2YgYSBVUkkuDQoNClBhdWwNCg0KRnJvbTog c2FhZyBbbWFpbHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWxsaXAg SGFsbGFtLUJha2VyDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTksIDIwMTUgOTowNCBBTQ0K VG86IHNhYWdAaWV0Zi5vcmcNClN1YmplY3Q6IFtzYWFnXSBBIFVSSSBmb3IgY3J5cHRvZ3JhcGhp YyBrZXlzDQoNClRoaXMgaGFzIGNvbWUgdXAgYSBmZXcgdGltZXMgaW4gdGhlIHBhc3QuIFRoaXMg dGltZSB0aG91Z2ggSSB3b3VsZCByZWFsbHkgbGlrZSB1cyB0byBnZXQgc29tZXRoaW5nIGRvbmUu DQoNCkluIGEgbnV0c2hlbGwsIGl0IHdvdWxkIGJlIHJlYWxseSB1c2VmdWwgaWYgdGhlcmUgd2Fz IGEgdHlwZSBvZiBVUkkgdGhhdCBjb3VsZCBiZSBzaW1wbHkgY3V0IGFuZCBwYXN0ZWQgdGhhdCB3 b3VsZCBzcGVjaWZ5IGVpdGhlcjoNCg0KKiBBIHVzZXIgYWNjb3VudCBhbmQgYSBtZWFucyBvZiBh dXRoZW50aWNhdGluZyBhIGNyZWRlbnRpYWwgdGhhdCBhdXRoZW50aWNhdGVzIHRoZSB1c2VyIG9m IHRoYXQgYWNjb3VudC4NCg0KKiBBbiBJbnRlcm5ldCBzZXJ2aWNlIGFuZCBtZWFucyBvZiBhdXRo ZW50aWNhdGluZyBhIGNyZWRlbnRpYWwgdGhhdCBhdXRoZW50aWNhdGVzIHRoYXQgc2VydmljZS4N Cg0KDQpTbyBsZXQgdXMgc2F5IHRoYXQgd2UgYXJlIHdvcmtpbmcgb24gQUNNRSBvciBEUFJJViBh bmQgd2UgYXJlIGxvb2tpbmcgZm9yIGEgd2F5IHRvIHRlbGwgdGhlIGNsaWVudCBvciBkZXZpY2Ug KG9yIHdoYXRldmVyKSB0aGF0IGl0IHNob3VsZCB1c2Ugc2VydmljZSBYIGFuZCBhdXRoZW50aWNh dGUgaXQgd2l0aCBrZXkgWS4NCg0KDQpGb3JnZXQgZm9yIGEgbWludXRlIHRoZSB1c2VyIGludGVy ZmFjZSBkZXRhaWxzIG9mIGhvdyB3ZSBhcnJpdmUgYXQgdGhpcyBwb2ludC4gQXQgc29tZSBwb2lu dCB3ZSBhcmUgZ29pbmcgdG8gY29tZSBkb3duIHRvIGEgRE5TIG5hbWUgYW5kIHNvbWUgbWVhbnMg b2YgYXV0aGVudGljYXRpbmcgdGhlIHNlcnZlciBrZXkgb24gdGhlIGNsaWVudCBzaWRlIGFuZCBh IHVzZXIgYWNjb3VudCBhbmQgYSBtZWFucyBvZiBhdXRoZW50aWNhdGluZyB0aGUgdXNlciBvbiB0 aGUgc2VydmVyIHNpZGUuDQoNCg0KV2hhdCBJIHdvdWxkIGxpa2UgaXMgYSBVUkkgZm9ybSB0aGF0 IHdvdWxkIGFsbG93IHRoaXMgdHlwZSBvZiByZWxhdGlvbnNoaXAgdG8gYmUgZGVzY3JpYmVkOg0K DQp1c2VyOmFsaWNlQGV4YW1wbGUuY29tOkF3UmhzeGJzU1U4cUktMXZxZlZhdnJLUQ0Kc2Vydmlj ZTpleGFtcGxlLmNvbTphY21lLnRjcDpBZV85ZmV6ZjNVQUJ1Q0U2bGxNWWREd0ENCg0KDQpUaGlu ayBvZiB0aGVzZSBhcyB0aGUgJ3RoaW4gd2Fpc3QnIGZvciBhdXRoZW50aWNhdGlvbiBtZWNoYW5p c21zLiBObyBtYXR0ZXIgd2hhdCB0aGUgYWN0dWFsIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBp cyBvciBob3cgdGhlc2UgY3JlZGVudGlhbHMgd2VyZSBlc3RhYmxpc2hlZCwgSSBjYW4gcHJvdmlk ZSBhIGRlc2NyaXB0aW9uIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFsIGluIHRoaXMg Zm9ybSBhbmQgdGhlbiB1c2UgaXQgdG8gdmVyaWZ5IHRoZSBhY3R1YWwgY3JlZGVudGlhbCBhZ2Fp bnN0LiBTQU1MLCBQS0lYLCBPcGVuSUQsIE9BVVRILCBLZXJiZXJvcywgZXZlcnl0aGluZyBjYW4g YmUgZXhwcmVzc2VkIGluIG9uZSBmb3JtLg0KDQp1c2VyOjxhY2NvdW50PkA8ZG5zLW5hbWU+Ojxh dXRoZW50aWNhdG9yPg0Kc2VydmljZTo8ZG5zLW5hbWU+OjxzZXJ2aWNlLXByZWZpeD46PGF1dGhl bnRpY2F0b3I+DQoNClRoZXNlIFVSSSBmb3JtcyBhcmUgdGhlIHNvcnQgb2YgdGhpbmcgd2UgbWln aHQgcHV0IGluIGEgY29uZmlndXJhdGlvbiBmaWxlIG9yIHRoZSB3aW5kb3dzIHJlZ2lzdHJ5IG9y IGFueSBvdGhlciBjb25maWd1cmF0aW9uIGZpbGUuIFRoZXkgYXJlIG5vdCBzb21ldGhpbmcgSSB0 aGluayB3ZSB3b3VsZCB3YW50IHRvIHRocnVzdCBpbiBmcm9udCBvZiB0aGUgdXNlcidzIGZhY2Uu IEJ1dCBoYXZpbmcgdGhlIGFiaWxpdHkgdG8gaGFuZGxlIHRoZW0gYXMgdGV4dCBzdHJpbmdzIHdp bGwgYmUgdmVyeSB1c2VmdWwgb24gb2NjYXNpb24uIFBhcnRpY3VsYXJseSBpZiB3ZSBhcmUgY29u ZmlndXJpbmcgYW4gZW1iZWRkZWQgZGV2aWNlIHZpYSBhIFVTQiBjYWJsZSBvciBzdWNoLg0KDQoN ClRoZSBhdXRoZW50aWNhdG9yIHBhcnQgY2FuIGJlIGVpdGhlciBkaXJlY3Qgb3IgaW5kaXJlY3Qu IEEgZGlyZWN0IGF1dGhlbnRpY2F0b3IgYmVpbmcgdGhlIGNyeXB0b2dyYXBoaWMga2V5IGl0c2Vs ZiBhbmQgYW4gaW5kaXJlY3QgYXV0aGVudGljYXRvciBiZWluZyBhIG1lYW5zIHRvIGF1dGhlbnRp Y2F0ZSB0aGUga2V5Lg0KDQpUaGUgY3J5cHRvZ3JhcGhpYyBrZXlzIHRoZW1zZWx2ZXMgbWF5IGJl IGVpdGhlciBhIHB1YmxpYyBrZXkgb3IgYSBrZXJiZXJvcyBsaWtlIHRpY2tldC4NCg0KDQpXaGlj aCB0eXBlIG9mIGF1dGhlbnRpY2F0b3Igd2Ugd2FudGVkIHRvIG1ha2UgdXNlIG9mIHdvdWxkIGRl cGVuZCBvbiB3aGF0IGxheWVyIHdlIGFyZSBpbiB0aGUgY3J5cHRvLXN0YWNrLg0KDQpBdCB0aGUg dmVyeSB0b3AgbGF5ZXIgdGhlIGF1dGhlbnRpY2F0b3Igd291bGQgcHJvYmFibHkgYmUgYSBTSEE1 MTItMjU2IG9yIFNIQTUxMi0xMjggZGlnZXN0IG9mIHRoZSByb290IG9mIHRydXN0IGluIGEgUEtJ LiBJZiBJIGFtIGNvbmZpZ3VyaW5nIGFuIEFDTUUgY2xpZW50IHRvIGNvbm5lY3QgdG8gdGhlIENv bW9kbyBDQSBmb3IgY2VydGlmaWNhdGUgaXNzdWUsIEkgcHJvYmFibHkgd2FudCB0aGUgYXV0aGVu dGljYXRvciB0byBiZSB0aGUgcm9vdCBvZiB0cnVzdCBmb3IgdGhlIENvbW9kbyBDQSwgaS5lLiBh IGRpZ2VzdCBvZiB0aGUga2V5aW5mbyBibG9jayBvZiBzb21lIENvbW9kbyByb290IGNlcnQuDQoN CkF0IHRoZSB2ZXJ5IGJvdHRvbSBjcnlwdG8gbGF5ZXIgd2Ugb25seSB1c2Ugc3ltbWV0cmljIGtl eXMuIFNvIHRoZSBhdXRoZW50aWNhdG9yIG1pZ2h0IGJlIGEgS2VyYmVyb3MgdGlja2V0IG9yIHRo ZSBsaWtlLiBPYnZpb3VzbHkgdGhpcyBpcyBub3QgdGhlIHR5cGUgb2YgY3JlZGVudGlhbCB5b3Ug d291bGQgdXN1YWxseSB3YW50IHRvIGhhdmUgbHlpbmcgYXJvdW5kIGluIGEgc3RhdGljIGNvbmZp ZyBmaWxlLg0KDQpJbiBiZXR3ZWVuIHdlIHdvdWxkIHByb2JhYmx5IGhhdmUgdXNlIGZvciB1c2lu ZyBhIHB1YmxpYyBrZXkgYXMgdGhlIGF1dGhlbnRpY2F0b3IuIE9yIGF0IGxlYXN0IHdpbGwgZG8g b25jZSB3ZSBnZXQgYSB+MjU2IGJpdCBFQ0MgYWxnb3JpdGhtIGFncmVlZC4gSSB3b3VsZCBub3Qg d2FudCB0byBjdXQgYW5kIHBhc3RlIHJhdyBSU0Ega2V5cyBidXQgbG90cyBvZiBwZW9wbGUgYXJl IGFscmVhZHkgZG9pbmcganVzdCB0aGF0IGZvciBDdXJ2ZTI1NTE5Lg0KDQoNCg0KDQoNCg== --_000_7BAC95F5A7E67643AAFB2C31BEE662D020E27DBD8ASCVEXCH2marve_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SeKAmW0gaW50ZXJlc3RlZCBpbiBjcnlwdG9n cmFwaHkgaW4gVVJJcyBvciBZVVJMcywgYnV0IGFtIHZlcnkgY29uZnVzZWQgYnkgwqB0aGUgcHJv cG9zYWwgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QZXJoYXBzIGEgbW9yZSBzdWNjaW5jdCB1 c2UgY2FzZSB3b3VsZCBoZWxwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SeKAmW0gd29ya2luZyBub3cg b24gdHJ5aW5nIHRvIGJpbmQgYSDigJhzZXJ2aWNl4oCZLCDigJhjb21tdW5pY2F0aW9uIGNoYW5u ZWzigJkgYW5kIGEgZXBoZW1lcmFsIHB1YmxpYyBrZXkgYXMgYSBZVVJMLWlzaCBpbnRyb2R1Y3Rp b24uwqAgVGhpcyB3b3VsZCBiZSBpbiBRUiBjb2RlcyB0byBzZWN1cmVseSBjb25uZWN0IHRvIGEg cmVsYXRlZCB3aXJlbGVzcyBQMlAgc2VydmljZS7CoCBUaGUgY2hhcmFjdGVyIGVuY29kaW5nIGlu IGEgUVItQ29kZSBtaWdodCBiZW5lZml0IGZyb20gdGhlIHVzZSBvZiBhIFVSSS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHNhYWcgW21haWx0bzpz YWFnLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbGxpcCBIYWxsYW0t QmFrZXI8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxOSwgMjAxNSA5OjA0IEFN PGJyPjxiPlRvOjwvYj4gc2FhZ0BpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW3NhYWddIEEg VVJJIGZvciBjcnlwdG9ncmFwaGljIGtleXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPlRoaXMgaGFzIGNvbWUgdXAgYSBmZXcgdGltZXMgaW4gdGhlIHBhc3QuIFRoaXMg dGltZSB0aG91Z2ggSSB3b3VsZCByZWFsbHkgbGlrZSB1cyB0byBnZXQgc29tZXRoaW5nIGRvbmUu PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SW4gYSBudXRzaGVsbCwgaXQgd291bGQg YmUgcmVhbGx5IHVzZWZ1bCBpZiB0aGVyZSB3YXMgYSB0eXBlIG9mIFVSSSB0aGF0IGNvdWxkIGJl IHNpbXBseSBjdXQgYW5kIHBhc3RlZCB0aGF0IHdvdWxkIHNwZWNpZnkgZWl0aGVyOjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiogQSB1c2VyIGFjY291bnQgYW5kIGEgbWVh bnMgb2YgYXV0aGVudGljYXRpbmcgYSBjcmVkZW50aWFsIHRoYXQgYXV0aGVudGljYXRlcyB0aGUg dXNlciBvZiB0aGF0IGFjY291bnQuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+KiBBbiBJbnRlcm5ldCBzZXJ2aWNlIGFuZCBtZWFucyBvZiBhdXRoZW50aWNhdGluZyBhIGNy ZWRlbnRpYWwgdGhhdCBhdXRoZW50aWNhdGVzIHRoYXQgc2VydmljZS48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5TbyBsZXQgdXMgc2F5IHRoYXQgd2UgYXJlIHdvcmtpbmcgb24gQUNN RSBvciBEUFJJViBhbmQgd2UgYXJlIGxvb2tpbmcgZm9yIGEgd2F5IHRvIHRlbGwgdGhlIGNsaWVu dCBvciBkZXZpY2UgKG9yIHdoYXRldmVyKSB0aGF0IGl0IHNob3VsZCB1c2Ugc2VydmljZSBYIGFu ZCBhdXRoZW50aWNhdGUgaXQgd2l0aCBrZXkgWS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Rm9yZ2V0IGZvciBhIG1pbnV0ZSB0aGUgdXNlciBpbnRl cmZhY2UgZGV0YWlscyBvZiBob3cgd2UgYXJyaXZlIGF0IHRoaXMgcG9pbnQuIEF0IHNvbWUgcG9p bnQgd2UgYXJlIGdvaW5nIHRvIGNvbWUgZG93biB0byBhIEROUyBuYW1lIGFuZCBzb21lIG1lYW5z IG9mIGF1dGhlbnRpY2F0aW5nIHRoZSBzZXJ2ZXIga2V5IG9uIHRoZSBjbGllbnQgc2lkZSBhbmQg YSB1c2VyIGFjY291bnQgYW5kIGEgbWVhbnMgb2YgYXV0aGVudGljYXRpbmcgdGhlIHVzZXIgb24g dGhlIHNlcnZlciBzaWRlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldoYXQgSSB3 b3VsZCBsaWtlIGlzIGEgVVJJIGZvcm0gdGhhdCB3b3VsZCBhbGxvdyB0aGlzIHR5cGUgb2YgcmVs YXRpb25zaGlwIHRvIGJlIGRlc2NyaWJlZDo8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD51c2VyOmFsaWNlQGV4YW1wbGUuY29tOkF3UmhzeGJzU1U4cUktMXZxZlZhdnJLUTxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNlcnZpY2U6ZXhhbXBs ZS5jb206YWNtZS50Y3A6QWVfOWZlemYzVUFCdUNFNmxsTVlkRHdBPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+VGhpbmsgb2YgdGhlc2UgYXMgdGhlICd0aGluIHdhaXN0JyBmb3IgYXV0 aGVudGljYXRpb24gbWVjaGFuaXNtcy4gTm8gbWF0dGVyIHdoYXQgdGhlIGFjdHVhbCBhdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20gaXMgb3IgaG93IHRoZXNlIGNyZWRlbnRpYWxzIHdlcmUgZXN0YWJs aXNoZWQsIEkgY2FuIHByb3ZpZGUgYSBkZXNjcmlwdGlvbiBvZiB0aGUgYXV0aGVudGljYXRpb24g Y3JlZGVudGlhbCBpbiB0aGlzIGZvcm0gYW5kIHRoZW4gdXNlIGl0IHRvIHZlcmlmeSB0aGUgYWN0 dWFsIGNyZWRlbnRpYWwgYWdhaW5zdC4gU0FNTCwgUEtJWCwgT3BlbklELCBPQVVUSCwgS2VyYmVy b3MsIGV2ZXJ5dGhpbmcgY2FuIGJlIGV4cHJlc3NlZCBpbiBvbmUgZm9ybS48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD51c2VyOiZsdDthY2NvdW50Jmd0O0AmbHQ7ZG5zLW5h bWUmZ3Q7OiZsdDthdXRoZW50aWNhdG9yJmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPnNlcnZpY2U6Jmx0O2Rucy1uYW1lJmd0OzombHQ7c2VydmljZS1wcmVm aXgmZ3Q7OiZsdDthdXRoZW50aWNhdG9yJmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPlRoZXNlIFVSSSBmb3JtcyBhcmUgdGhlIHNvcnQgb2YgdGhpbmcgd2UgbWlnaHQg cHV0IGluIGEgY29uZmlndXJhdGlvbiBmaWxlIG9yIHRoZSB3aW5kb3dzIHJlZ2lzdHJ5IG9yIGFu eSBvdGhlciBjb25maWd1cmF0aW9uIGZpbGUuIFRoZXkgYXJlIG5vdCBzb21ldGhpbmcgSSB0aGlu ayB3ZSB3b3VsZCB3YW50IHRvIHRocnVzdCBpbiBmcm9udCBvZiB0aGUgdXNlcidzIGZhY2UuIEJ1 dCBoYXZpbmcgdGhlIGFiaWxpdHkgdG8gaGFuZGxlIHRoZW0gYXMgdGV4dCBzdHJpbmdzIHdpbGwg YmUgdmVyeSB1c2VmdWwgb24gb2NjYXNpb24uIFBhcnRpY3VsYXJseSBpZiB3ZSBhcmUgY29uZmln dXJpbmcgYW4gZW1iZWRkZWQgZGV2aWNlIHZpYSBhIFVTQiBjYWJsZSBvciBzdWNoLiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBhdXRoZW50aWNhdG9yIHBhcnQgY2Fu IGJlIGVpdGhlciBkaXJlY3Qgb3IgaW5kaXJlY3QuIEEgZGlyZWN0IGF1dGhlbnRpY2F0b3IgYmVp bmcgdGhlIGNyeXB0b2dyYXBoaWMga2V5IGl0c2VsZiBhbmQgYW4gaW5kaXJlY3QgYXV0aGVudGlj YXRvciBiZWluZyBhIG1lYW5zIHRvIGF1dGhlbnRpY2F0ZSB0aGUga2V5LjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBjcnlwdG9ncmFwaGljIGtleXMgdGhlbXNlbHZl cyBtYXkgYmUgZWl0aGVyIGEgcHVibGljIGtleSBvciBhIGtlcmJlcm9zIGxpa2UgdGlja2V0Ljxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldoaWNoIHR5cGUgb2YgYXV0aGVudGljYXRv ciB3ZSB3YW50ZWQgdG8gbWFrZSB1c2Ugb2Ygd291bGQgZGVwZW5kIG9uIHdoYXQgbGF5ZXIgd2Ug YXJlIGluIHRoZSBjcnlwdG8tc3RhY2suJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+QXQgdGhlIHZlcnkgdG9wIGxheWVyIHRoZSBhdXRoZW50aWNhdG9yIHdvdWxk IHByb2JhYmx5IGJlIGEgU0hBNTEyLTI1NiBvciBTSEE1MTItMTI4IGRpZ2VzdCBvZiB0aGUgcm9v dCBvZiB0cnVzdCBpbiBhIFBLSS4gSWYgSSBhbSBjb25maWd1cmluZyBhbiBBQ01FIGNsaWVudCB0 byBjb25uZWN0IHRvIHRoZSBDb21vZG8gQ0EgZm9yIGNlcnRpZmljYXRlIGlzc3VlLCBJIHByb2Jh Ymx5IHdhbnQgdGhlIGF1dGhlbnRpY2F0b3IgdG8gYmUgdGhlIHJvb3Qgb2YgdHJ1c3QgZm9yIHRo ZSBDb21vZG8gQ0EsIGkuZS4gYSBkaWdlc3Qgb2YgdGhlIGtleWluZm8gYmxvY2sgb2Ygc29tZSBD b21vZG8gcm9vdCBjZXJ0LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkF0 IHRoZSB2ZXJ5IGJvdHRvbSBjcnlwdG8gbGF5ZXIgd2Ugb25seSB1c2Ugc3ltbWV0cmljIGtleXMu IFNvIHRoZSBhdXRoZW50aWNhdG9yIG1pZ2h0IGJlIGEgS2VyYmVyb3MgdGlja2V0IG9yIHRoZSBs aWtlLiBPYnZpb3VzbHkgdGhpcyBpcyBub3QgdGhlIHR5cGUgb2YgY3JlZGVudGlhbCB5b3Ugd291 bGQgdXN1YWxseSB3YW50IHRvIGhhdmUgbHlpbmcgYXJvdW5kIGluIGEgc3RhdGljIGNvbmZpZyBm aWxlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkluIGJldHdlZW4gd2Ug d291bGQgcHJvYmFibHkgaGF2ZSB1c2UgZm9yIHVzaW5nIGEgcHVibGljIGtleSBhcyB0aGUgYXV0 aGVudGljYXRvci4gT3IgYXQgbGVhc3Qgd2lsbCBkbyBvbmNlIHdlIGdldCBhIH4yNTYgYml0IEVD QyBhbGdvcml0aG0gYWdyZWVkLiBJIHdvdWxkIG5vdCB3YW50IHRvIGN1dCBhbmQgcGFzdGUgcmF3 IFJTQSBrZXlzIGJ1dCBsb3RzIG9mIHBlb3BsZSBhcmUgYWxyZWFkeSBkb2luZyBqdXN0IHRoYXQg Zm9yIEN1cnZlMjU1MTkuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_7BAC95F5A7E67643AAFB2C31BEE662D020E27DBD8ASCVEXCH2marve_-- From nobody Tue Feb 24 05:56:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741371A1A82; Tue, 24 Feb 2015 05:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVO8OZdGVRfH; Tue, 24 Feb 2015 05:56:23 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C05D1A1AE6; Tue, 24 Feb 2015 05:56:23 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 5038ce45.0.4798030.00-2331.13494641.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 24 Feb 2015 13:56:23 +0000 (UTC) X-MXL-Hash: 54ec830719bcac5e-253cd24390c5f32065b2bfebe308a4f61dbb9c7c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODuKB3008578; Tue, 24 Feb 2015 08:56:20 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODuGF1008562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Feb 2015 08:56:18 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 24 Feb 2015 13:56:04 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODu3ZD005610; Tue, 24 Feb 2015 08:56:04 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODtuZ6005177; Tue, 24 Feb 2015 08:55:56 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224135555gw1000ceefe>; Tue, 24 Feb 2015 13:55:56 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54EC82EB.3040705@att.com> Date: Tue, 24 Feb 2015 08:55:55 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG] X-AnalysisOut: [9nkA:10 a=KWikpAkKAAAA:8 a=aQeYOMMR6rlqqqAHQZoA:9 a=QEXdDO] X-AnalysisOut: [2ut3YA:10 a=zdbJd93gu_dgrkFV:21 a=MGKYglSutNO77KFl:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: kitten@ietf.org, "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 13:56:29 -0000 On 2/18/15 7:57 AM, Sam Whited wrote: > On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland wrote: >> Worth asking in the XSF, there's likely to be implementation experience from >> the Android client devs there. > I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't > remember actual numbers off the top of my head, I can definitely tell > you that there is a noticable delay with a 4096 iteration count > (probably a little over half a second) on my HTC m7 (which is fairly > beefy as far as phones go). HOWEVER— > >> However, clients need only do the iterations once, if the salt is stable, at >> least in principle. > —since we then store the session information in an LRU Cache in > memory, it's only slow when you first login. I've thought about moving > the session info to the database as well to make it even more > persistant, but decided it wasn't enough of a problem to bother > polluting the database. We have implementations of both SCRAM-SHA-1 and SCRAM-SHA-256 on multiple phone platforms, both Android and iOS. Yes, it can be rather slow. But, as Sam says above, caching does mitigate the issue for subsequent uses. This is why I pushed back when it was suggested before in KITTEN to raise the number higher than 4096. Tony Hansen