From msec-bounces@securemulticast.org Wed Sep 1 09:23:09 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04101 for ; Wed, 1 Sep 2004 09:23:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 397FC8E5CB; Wed, 1 Sep 2004 08:56:20 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 924408E5BC for ; Wed, 1 Sep 2004 08:56:19 -0400 (EDT) Received: (qmail 61883 invoked by uid 3269); 1 Sep 2004 12:56:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61880 invoked from network); 1 Sep 2004 12:56:19 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 1 Sep 2004 12:56:19 -0000 Received: (qmail 50257 invoked from network); 1 Sep 2004 08:56:16 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 1 Sep 2004 08:56:16 -0400 Received: (qmail 70908 invoked from network); 1 Sep 2004 08:56:15 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.196) by mail1.oct.nac.net with SMTP; 1 Sep 2004 08:56:15 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i81ASXO02965; Wed, 1 Sep 2004 06:28:33 -0400 Date: Wed, 1 Sep 2004 06:28:33 -0400 (EDT) From: George Gross To: Marg Subject: Re: [MSEC] problem with keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Marg, On Wed, 1 Sep 2004, Marg wrote: > Hello, i'm searching about a possible solution in reliable multicast did you mean to say "authenticated" rather than "reliable" in above text? > communications. what i would like to now is if there is a solution for > managing keys in this way: is it possible to use several private keys > associated with a singolar public key? I am not sure if I understand your question. However, what you are asking about sounds almost like probablistic encryption, but using it in the reverse direction for digital signature source authentication. However, AFAIK, probablistic encryption is a single key pair, not 1 public and N private keys. Probablistic encryption does have the unusual property that a single plaintext can be represented by multiple equivalent ciphertexts. > I mean, let's consider the case > of one sender and n receivers. Each receiver has a different private > key. I am confused. In this sentence, did you mean to say "sender" rather than "receiver"? > If they use their own key to encript a message, can the sender > use a unique public key to decript the n messages? When you say "encrypt", I assume you mean a sender encrypts a hash digest of the multicast message as its source authentication signature, correct? When you say "decrypt" I'm guessing you really meant to say that the group's receivers verify the signature of the multicast message? > Do you know if such > algorithm exists or is it in phase of study? Thank you Margherita You can find an introduction to probablistic encryption in Schneir's "Applied Cryptography" section 23.15. I do not know if it is feasible for it to be extended for use in your application. hth, George > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From mailman-bounces@six.pairlist.net Wed Sep 1 09:57:00 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13675 for ; Wed, 1 Sep 2004 09:57:00 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5C7558DBCA for ; Wed, 1 Sep 2004 05:04:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: securemulticast.org mailing list memberships reminder From: mailman-owner@securemulticast.org To: msec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Sep 2004 05:01:24 -0400 Precedence: bulk X-BeenThere: mailman@six.pairlist.net X-Mailman-Version: 2.1.5 List-Id: mailman.six.pairlist.net X-List-Administrivia: yes Sender: mailman-bounces@six.pairlist.net Errors-To: mailman-bounces@six.pairlist.net Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your securemulticast.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@securemulticast.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@securemulticast.org. Thanks! Passwords for msec-archive@lists.ietf.org: List Password // URL ---- -------- msec@securemulticast.org ucweat http://six.pairlist.net/mailman/options/msec/msec-archive%40lists.ietf.org From msec-bounces@securemulticast.org Wed Sep 1 10:12:39 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16449 for ; Wed, 1 Sep 2004 10:12:38 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 976288C321; Wed, 1 Sep 2004 06:42:21 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8D3F38C405 for ; Wed, 1 Sep 2004 06:42:19 -0400 (EDT) Received: (qmail 41698 invoked by uid 3269); 1 Sep 2004 10:42:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41695 invoked from network); 1 Sep 2004 10:42:19 -0000 Received: from smtp0.libero.it (193.70.192.33) by klesh.pair.com with SMTP; 1 Sep 2004 10:42:19 -0000 Received: from localhost (172.16.1.83) by smtp0.libero.it (7.0.027-DD01) id 40D2BD6000F1F9E4 for msec@securemulticast.org; Wed, 1 Sep 2004 12:42:18 +0200 Received: from libero.it (172.16.1.123) by smtp20.libero.it (7.0.027-DD01) id 40E3F8E400445A67 for msec@securemulticast.org; Wed, 1 Sep 2004 12:42:18 +0200 Date: Wed, 1 Sep 2004 12:42:18 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Marg" To: "msec" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.149 X-Virus-Scanned: by amavisd-new at libero.it Subject: [MSEC] problem with keys X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hello, i'm searching about a possible solution in reliable multicast com= munications. what i would like to now is if there is a solution for mana= ging keys in this way: is it possible to use several private keys associa= ted with a singolar public key? I mean, let's consider the case of one s= ender and n receivers. Each receiver has a different private key. If th= ey use their own key to encript a message, can the sender use a unique pu= blic key to decript the n messages? Do you know if such algorithm exists= or is it in phase of study? Thank you Margherita _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 2 02:39:57 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07235 for ; Thu, 2 Sep 2004 02:39:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1B47D8D4BE; Thu, 2 Sep 2004 02:39:56 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 07B598D4A9 for ; Thu, 2 Sep 2004 02:39:54 -0400 (EDT) Received: (qmail 78525 invoked by uid 3269); 2 Sep 2004 06:39:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78522 invoked from network); 2 Sep 2004 06:39:53 -0000 Received: from saturn.bt.com (HELO cbibipnt05.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 2 Sep 2004 06:39:53 -0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SABGTSPJ; Thu, 2 Sep 2004 07:39:59 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1094107198237; Thu, 2 Sep 2004 07:39:58 +0100 Received: from mut.jungle.bt.co.uk ([132.146.127.89]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i826dL7W021717; Thu, 2 Sep 2004 07:39:40 +0100 Message-Id: <5.2.1.1.2.20040902060922.028d12f0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Sep 2004 07:23:27 +0100 To: From: Bob Briscoe Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: elisabetta.carrara@ericsson.com, mbaugher@cisco.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Atul, At 19:39 30/08/2004, Atul.Sharma@nokia.com wrote: >Just trying to understand from confusing inlining.... I tried to be careful with inlining - what's the problem? >One of the high order bits of the discussion is the question: > > Should Group-MAC, to provide group authentication and prevent > DoS attacks from outside the group, be MANDATED or NOT? Just to be clear, group authentication just says each streamed packet came from /someone/ who knew the group key. TESLA is for scenarios where you need source authentication to say precisely who they came from, which should mean you don't need group authentication. But TESLA source authentication is delayed a hundred msec or so. So, if there's a threat of DoS, you need something (cheap) in the mean time. Options for these ~100msec: - a group MAC as well (as in current SRTP draft) = bigger packets - the S/KEY-like scheme in 3/ below = more sender memory/processing There are applicability issues with both these options. The TESLA-intro authors have decided to write up these issues in a further TESLA-intro draft. I'd be interested in opinions in the mean time, but you might want to wait until the issues are laid out clearly. >and the related question: > > The base TESLA intro draft does not mandate it, how come > SRTP-TESLA draft is mandating it? Again, to be clear, the TESLA-intro draft will be INFORMATIONAL, so isn't in a position to mandate anything. It should give advice for those writing the specific instantiations, of which SRTP-TESLA is one. A specific instantiation needs to say, MUST/SHOULD/MAY etc. >Thinking out loud, mandating Group-MAC has the advantage of less >interoperability >woes. On the flip side making it optional has the advantage of saving >byte-overhead >per packet and a bit of computation time, when Group-MAC is not used. >Mark, points >out extra space needed should actually be 4 bytes as opposed to 10 bytes >mentioned >in the SRTP-TESLA draft. Pending Elisabetta checking why it said 10. >Since presence of Group-MAC can be a group policy, which in the case of >Multicast >security is enforced rather than negotiated, I would guess >interoperability issues >should not crop up. So making it optional may not actually lead to >interoperability >woes. Yes, interoperability isn't the issue. Implementation and usage complexity of having options /is/ a concern. Chances of security holes increase, both due to complexity bugs and due to inappropriate choice of options for a particular scenario. Another possibility is to define completely separate transforms instead of options within a transform, but I don't fully understand the complexity implications of each way forward. Can anyone help here? >What do other members on MSEC mailing list think? Mandate or not Mandate >Group-MAC >in the base TESLA protocol? IMHO, Once we decide that, we can talk about >what to do >in SRTP-TESLA, if at all any different. See above, for process clarification. Bob >Best, >Atul > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Mark Baugher > > Sent: Monday, August 30, 2004 1:50 PM > > To: Bob Briscoe > > Cc: elisabetta.carrara@ericsson.com; msec@securemulticast.org > > Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) > > > > > > Bob, > > I reply to many of your points below, but here is > > something I'd like > > for you and your co-authors to consider: Apart from reusing the RTP > > timestamp field the issue you raise in point 3 is a general > > TESLA issue > > and not an SRTP-TESLA issue. I think this is also true for > > guidance on > > the use or non-use of a group MAC, which is related to your > > point 3. > > I'd like to see these points treated in a general way so why not > > critique the base TESLA spec on this point and not SRTP-TESLA? > > > > More below... > > On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: > > > > > ... > > > I'm not sure whether you're misunderstanding me, or just > > agreeing, but > > > sounding as if you disagree. In no way am I proposing > > anything that > > > doesn't do strong integrity checking. > > > > I understand that. > > > > > > > ... > > > Having thought about it, I will be stronger than the last > > mail and say > > > a group MAC will provide barely any additional protection in most > > > circumstances so should not be the default. The logic of > > using a group > > > MAC with TESLA looks like this: > > > > > > Sender's level of trust in group members not to spoof packets > > > | using a group key? | > > > Low High > > > | | > > > Use source authentication (ie TESLA). Use group > > > authentication. > > > | > > > TESLA is vulnerable to DoS filling buffer > > > until delayed auth > > > | > > > Use group authentication alongside TESLA > > > (as in current SRTP draft) > > > > > > I hope this diagram helps highlight the broken logic. > > > Group authentication is being MANDATED in the SRTP draft in > > a scenario > > > which only ever arises where the group isn't trusted. > > > > Trusted to do or not do what? I think in this case, "trusted" means > > "trusted not to launch a denial of service attack against the > > group." > > There is also "trusted not to capture a disclosed key to > > successfully > > impersonate a group sender." Further, there is "trusted not to > > disclose a group key" - and so on. Treating something as > > complicated > > as this as "high" or "low" is not persuading me, personally. > > > > > dding group authentication to TESLA only provides any > > additional value > > > for the narrow range of scenarios where group members > > aren't trusted > > > enough to use group authentication alone, but they are trusted > > > sufficiently that group authentication might detect some > > DoS attacks - > > > pretty slim odds. Worth allowing as an option, but surely not > > > MANDATING. > > > > You see a waste of time and bandwidth for protection that is > > superfluous. I see a relatively cheap way to keep a group protected > > against anyone running a kiddie script who decides to send a > > burst of > > packets and overflow members' buffers. Let's gather some > > more opinion > > from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. > > > > > ... > > > > > > I had thought about the ramifications fairly carefully > > before saying > > > this. I suggest that the way to deal with the TESLA time interval > > > identifier, I, is to: > > > - remove I from the default TESLA-SRTP packet format > > > - explain how to derive I from the RTP timestamp > > > > I may have confused you in my last note in trying to explain all the > > ways that I think overloading protocol fields for security > > purposes is > > generally not a good idea. Let me try to state this clearly: > > The RTP > > timestamp is used for specific purposes for RTP payload types > > that are > > unrelated to sender authentication, and it is quite possible that we > > will either interfere with these uses by placing TESLA-induced > > constraints on that field or weaken TESLA security when we find > > surprising uses are made of that field by certain applications. > > > > Re-use of the RTP Timestamp in TESLA can be easily avoided by > > adding a > > TESLA timetamp field in the packet. I think the points you > > are raising > > are important and helpful to SRTP-TESLA. But it would > > helpful if you > > separated them I think. Re-use of the RTP timestamp, the > > non-mandatory > > group MAC, and your proposal under point 3 can stand by > > themselves. I > > think we have 3 threads here and not one. > > > > > - MANDATE that a sender authentication module should use a > > TESLA key > > > interval derived from the RTP timestamp, not the clock > > > - warn implementors that any delay in the sender stack will > > add to the > > > TESLA authentication delay (but not weaken it) > > > - (if we can think of any other problems ) warn > > implementors what to > > > watch out for when overloading the RTP timestamp function > > (I'm fairly > > > sure there aren't any - and I've thought long and hard) > > > > I'd prefer to use a separate field. At minimum, I would take > > this to > > AVT for further discussion. I don't think the gain from > > overloading is > > worth any unexpected pitfalls, particularly security > > pitfalls. RTP is > > a special beast because it is used in so many types of applications, > > from telephony to client/server multimedia, from unicast-pairwise to > > unicast-group, small multicast conferences to large-scale broadcast, > > etc. > > > > > - make I optional in the TESLA-SRTP packet format for > > implementors to > > > use if they are in one of these obscure scenarios > > > > > > > > >>> If the sender buffers packets between adding the RTP timestamp and > > >>> adding TESLA authentication fields, this will add to the TESLA > > >>> authentication delay. But a good RTP implementation shouldn't be > > >>> doing > > >>> serious buffering here. > > >> > > >> What about high-bandwidth, server/playback media such as > > movies? In > > >> fact, let me try this: What about an MPEG packetizer that > > does a lot > > >> of pre-processing of the MPEG AUs prior to assigning them > > to packets. > > >> This might happen because the AUs were encrypted and > > required a lot of > > >> pre-processing. Maybe there would be a two-step process > > applied to > > >> one > > >> or more AUs in which timetamps are assigned during some > > processing and > > >> then everything gets sent. > > >> Maybe such a problem can be avoided in packetizers. There > > are a lot > > >> of > > >> considerations when we take an existing field such as the RTP > > >> timestamp > > >> and add new functions to it. > > > > > > As long as we mandate that the TESLA sender uses the key > > appropriate > > > to the time interval derived from the RTP timestamp (not from the > > > clock), the protocol is safe. The TESLA safety test is > > still accurate. > > > > > > Any delay after RTP has determined its timestamp then folds > > into the > > > delay between sender and receiver that TESLA is designed to handle > > > safely. Of course, this makes the delay longer, which /delays/ > > > authentication. But it doesn't /weaken/ authentication. See > > section 4 > > > of the TESLA intro for discussion of similar scenarios (eg TCP > > > buffering). > > > > > > If authentication delay is a problem for a particular > > scenario, and > > > it's some odd scenario like you suggest where a large part of the > > > delay is within the sender stack between RTP and TESLA, then the > > > implementor can choose to use an explicit I in the packet. > > > > TESLA is complex enough without adding protocol dependencies > > like this > > in my view. > > > > > > > >> If the functions are really identical, then they are > > redundant. I > > >> tend > > >> to doubt that. > > > > > > I'd rather say that the functions of the two fields are invariably > > > equivalent, but may not be in some scenarios, when it's up to the > > > implementor to use the option of an explicit I. > > > > This new option will double the signaling, implementation, > > testing, and > > operational complexity of the protocol. > > > > > > > > >>> 2/ Non-TESLA group authentication to protect against DoS should be > > >>> optional > > >>> > > --------------------------------------------------------------------- > > >>> -- ---- > > >>> The immediate authentication provided by your non-TESLA group > > >>> authentication only protects against DoS by non-group members. It > > >>> should be RECOMMENDED not REQUIRED (section 7). > > >> > > >> I think that this point should be resolved in the base TESLA > > >> specification, i.e. I don't think there is anything that is > > >> SRTP-specific to this point. But we did not treat it that way in > > >> SRTP-TESLA, and that's probably my fault. Nonetheless, I think it > > >> should be REQUIRED in base TESLA. > > > > > > Currently section 5 (security considerations) of the TESLA-intro > > > mentions group authentication as one possible way of preventing > > > flooding attacks during the key disclosure delay. But it doesn't > > > MANDATE it. I'm simply taking issue with group > > authentication being > > > MANDATED in SRTP-TESLA, as I don't think it's effective in many > > > (most?) scenarios, making it unnecessary overhead. > > > > > > I have no problem with making a group MAC optional for > > scenarios where > > > it does improve matters. > > > > I don't have a lot of religious fervor on the topic either though I > > like to avoid options in security protocols whenever possible. What > > seemed fairly obvious to me obviously seems wasteful to you. > > I'd like > > to discuss this further in a separate thread. We are really > > discussing > > a security requirement for protecting groups. > > > > > ... > > > > > > > > Sorry, history was a distracting word. I meant likelihood. > > Imagine a > > > video conf between senior execs of competing companies, or between > > > representatives of mutually distrusting governments. They > > don't trust > > > each other not to spoof what the other parties are saying, > > but they > > > have no likelihood of one launching a flooding attack on the other > > > (e.g. the whole thing is over a joint VPN). They need group > > > authentication like a phish needs a bicycle. So why MANDATE it? > > > > We are beating this to death and confusing one another. The > > participants would not launch the flooding attack; an > > interloper would > > do it. If it's over a VPN, then the attack seems very > > unlikely - as is > > source spoofing in a small teleconference, for that matter. > > > > > ... > > > > > >> relies upon the fact that memory gets tied up while > > >> packets are buffered awaiting authentication. In this > > case, there is > > >> no buffering of multiple packets, just one packet during the > > >> disclosure > > >> interval. Do I understand you correctly? > > > > > > No. The disclosure *interval* (delay) still spans multiple > > packets. > > > The new feature depends on each key now only ever being > > *disclosed* > > > once, rather than the same key being disclosed repeatedly > > as it was > > > when there were multiple packets in the same TESLA time interval. > > > > Before we go any further into this, I'd like to understand why this > > disclosure scheme needs to be considered only for SRTP. You mention > > below that you also think that it belongs in the base TESLA > > specification and that you have raised the issue with your > > co-authors? > > I think the TESLA co-authors might want to consider > > discussing this on > > the list. That sounds better than treating SRTP-TESLA as the poster > > child for something that was maybe overlooked in the base TESLA > > document. > > > > I just got back from some personal time off and am working through > > several hundred messages - I prioritized yours. It would be a more > > efficient discussion to discuss this with the TESLA authors - on the > > msec list if possible. > > > > > > > > As soon as a packet arrives, the disclosed key in it now has two > > > purposes: > > > - it's original TESLA purpose: to verify a packet received > > some time > > > previously > > > - to immediately show the receiver that the sender of this > > packet knew > > > the next key back along the hash chain which is now only ever > > > *disclosed* once > > > > > > So if more packets are received that *disclose* the same key, the > > > receiver can assume (at least until the delayed TESLA > > verification) > > > that only the first packet to disclose each key was genuine. > > > > > > If a network element is compromised, an attacker can > > discover the next > > > disclosed key and overtake or replace a genuine packet with many > > > others. But the receiver can still immediately discard all but the > > > first to arrive, protecting itself from memory overflow. > > > > > > So the scheme has the following properties: > > > - The receiver will never buffer more than one packet per > > packet sent > > > by the genuine sender (so the receiver's buffer fill rate is still > > > clocked by the party that reveals each new key backwards in the > > > chain). > > > - As each key is later disclosed, TESLA can do delayed > > verification of > > > these stored packets. > > > - if they pass delayed verfication, the messages must be genuine > > > - if they fail delayed verfication, the messages must not > > have been > > > genuine > > > - The true message will have been lost in the latter case. > > But, then > > > if an attacker can compromise a network element, it can > > discard the > > > true messages anyway (a group MAC can't prevent this either ;) > > > > > > I need to fully document this. There are some corner cases > > not covered > > > by the above. I've given an outline later. Obviously, this DoS > > > protection idea hasn't had the same peer-review as TESLA, > > except it is > > > essentially just S/KEY, which has had ample peer review > > (but perhaps > > > not in a group setting). > > > > This sounds promising to me, but I would like to see the > > document - I > > have not read the one you sent me yet. And I would like to > > hear what > > the other TESLA authors have to say about it. > > > > > > > > > > ... > > >> If so, why > > >> not put this in the core TESLA specification. I'd say that if it > > >> belongs in SRTP-TESLA, then it belongs in the core > > specification. No? > > > > > > You are absolutely correct. > > > > > > We (the co-authors of the TESLA base spec) are discussing this > > > off-line right now. It's my fault we didn't reach closure > > on it before > > > TESLA got this far. I was originally pushing this as an > > option, but I > > > think I never quite got myself understood. Somewhere in the > > mists of > > > time I gave up. I've been taking a back seat on the TESLA > > work until > > > just recently, so my brain obviously wasn't in gear when reviewing > > > drafts. I forgot I'd got this option to attack the DoS > > problem. It was > > > only through reveiwing the SRTP draft that the technique > > came back to > > > me. Now, the more I argue about it, the better I think it is. > > > > > > However, it's not out of the woods yet. My co-authors are > > trying to > > > break it. I believe I've defended it in the case of > > variable packet > > > rate and packet misordering. But I'm expecting more > > attempts to break > > > it (and, of course, anyone on this list is welcome to try as well). > > > > > > If it comes out intact, you should see text on it shortly. > > Otherwise, > > > I guess the TESLA base spec will stay as it is. > > > > And this sizable email exchange would be in vain :?) > > > > > > > > > > ... > > >>> BTW, it should be pointed out that the verification algo > > should check > > >>> the key index is within an expected range before using it > > (e.g. only > > >>> a > > >>> small increment above the last highest verified key index seen). > > >>> Otherwise, an attacker can tamper with this field to lead all > > >>> receivers to run millions of hash operations > > unnecessarily. I prefer > > >>> to call it a key-index *hint*, to remind me not to rely > > on it being > > >>> correct. > > >> > > >> This sounds like an argument for keeping the MAC. > > > > > > No. It is an argument for watching that it doesn't appear to imply > > > packets are extremely re-ordered (e.g. it must be no more > > than, say, > > > 64 different from the previous highest index, cf the SRTP replay > > > protection window). You /could/ use a group MAC to do an > > initial test > > > of its integrity, but why waste 10 octets when you can do a > > test that > > > uses none? And this would only work if you trusted the > > group members > > > (recall, we are using TESLA because we don't trust them). > > > > The group MAC was originally 4 bytes and I need to check with > > Elisabetta to find out why it is now 10. I don't see why it > > needs to > > be larger than 4 bytes for group MAC purposes. If we manage > > to obviate > > the need for group MACs in TESLA, then it can be zero bytes > > and I'll be > > perfectly happy. > > > > > > The key index is implicitly authenticated (similar to the implicit > > > header authentication in section 9.5.2 of the SRTP RFC) > > because the > > > TESLA MAC depends on it. If the key index is tampered with, the > > > authentication test will fail as it should. > > > > Ok. > > > > > > > > ... > > >> > > >> We'll refer to your editorial comments at the next revision. > > > > > > I've added a couple more below... > > > > Good. How do you feel about my proposal to consider the > > proposed use > > of the RTP timestamp field separately from the group MAC. And treat > > the group MAC as a related question to your point 3 scheme? > > > > thanks, Mark > > > > > >> thanks, Mark > > > > > > And many thanks to you too, for doing all the hard work on these > > > drafts. > > > > > > more comments follow... > > > > > > > > >>> Nits > > >>> ==== > > >>> A general point of style: I found the spec had too much 'knitting > > >>> together by reference' from other specs. As Ran said in an earlier > > >>> posting, it needs at least some sketching of what is referred to. > > >>> Otherwise it is unlikely to lead to safe standardisation of > > >>> implementations. Particularly given that the references > > themselves > > >>> are > > >>> evolving, it becomes unsafe to expect people to find discrepancies > > >>> when reviewing this draft by re-reading the latest drafts of the > > >>> other > > >>> specs each time. Sections 4.4. & 4.4.1 were particular culprits. > > >>> However, I also have some sympathy with the view that > > duplication of > > >>> parts of specs in other specs can lead to inconsistency. > > > > > > The particular point was that the TESLA delay safety test > > is missing > > > from 4.4.2, but strictly you have said it must be done earlier (in > > > 4.4) by referring to the TESLA-intro. I think it should be > > in the list > > > of things the receiver should do. > > > > > > > > >>> Throughout: To be consistent with the TESLA intro, the time-slot > > >>> index, I, should be i (lower case). > > > > > > I now realise that lower case i would conflict with the SRTP spec. > > > > > >>> Sec 2. "...may often used..." --> "...may often be used..." > > >>> Sec 3. "This specification assumes that the reader is > > familiar with > > >>> TESLA" repeats the same sentence in Sec 1.1. > > >>> Sec 3. TESLA synch protocol & initial bootstrapping > > outside scope, > > >>> but > > >>> presumably you will include a ref once one is available. > > >>> Sec 4. "...and the delayed-authentication TESLA elements > > of procedure > > >>> [TESLA]." Garbled sentence? > > >>> Sec 4.1 "showed" --> "shown" > > >>> Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." > > > > > > Sec 4.3 bullet 10, uses same n_c notation as bullet 2 (but for > > > something else) > > > > > >>> Sec 4.4 "If the safe condition does not hold,..." add "...and the > > >>> event SHOULD be logged." > > > > > > Sec 4.4.2: "...perform verification of the SRTP integrity > > protection > > > tag..." this terminology hasn't been used in this draft (it was in > > > SRTP). Here it is just labelled the SRTP MAC. > > > Sec 4.4.2: "...using the rollover counter from the current > > packet,..." > > > -> "...using the rollover counter from the current context,..." > > > Sec 4.5: It might be worth starting this section by discussing the > > > applicability of authenticating RTCP receiver reports in > > large-scale > > > multicast settings. Possibly referring to section 11.2 and > > other parts > > > of the SRTP spec on the applicability and scalability of RTCP > > > authentication in multicast. > > > > > >>> Sec 5. TESLA doesn't assume local clocks don't drift too > > much. Rather > > >>> it requires a bound on clock drift to be known. > > >>> Sec 7. "...an in the TESLA specification..." --> "...and > > in the TESLA > > >>> specification..." > > >>> Sec 7. "...noted that the all TESLA security..." sentence garbled. > > > > > > > > > Cheers > > > > > > > > > > > > Bob > > > > > > > > > > > ______________________________________________________________ > > _________ > > > _____ > > > Notice: This contribution is the personal view of the > > author and does > > > not necessarily reflect the technical nor commercial > > direction of BT > > > plc. > > > > > ______________________________________________________________ > > _________ > > > _____ > > > Bob Briscoe, Networks Research > > Centre, BT > > > Research > > > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > +44 1473 > > > 645196 > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://six.pairlist.net/mailman/listinfo/msec > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 2 03:23:01 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09248 for ; Thu, 2 Sep 2004 03:23:00 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D7FFA8D026; Thu, 2 Sep 2004 03:23:00 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 238D48D01A for ; Thu, 2 Sep 2004 03:22:59 -0400 (EDT) Received: (qmail 85130 invoked by uid 3269); 2 Sep 2004 07:22:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85127 invoked from network); 2 Sep 2004 07:22:58 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 2 Sep 2004 07:22:58 -0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i827MvAh006168 for ; Thu, 2 Sep 2004 09:22:57 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 09:22:57 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 09:22:57 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BC3C4@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: "'Bob Briscoe'" , Atul.Sharma@nokia.com Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Thu, 2 Sep 2004 09:18:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Sep 2004 07:22:57.0670 (UTC) FILETIME=[ABAD5A60:01C490BD] Cc: mbaugher@cisco.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org > > >Thinking out loud, mandating Group-MAC has the advantage of less > >interoperability > >woes. On the flip side making it optional has the advantage > of saving > >byte-overhead > >per packet and a bit of computation time, when Group-MAC is > not used. > >Mark, points > >out extra space needed should actually be 4 bytes as opposed > to 10 bytes > >mentioned > >in the SRTP-TESLA draft. > > Pending Elisabetta checking why it said 10. The group MAC is default 4 bytes in the SRTP-TESLA draft. Please point me out if any text in the draft says differently. /E _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 2 04:02:24 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11099 for ; Thu, 2 Sep 2004 04:02:23 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A4FAF8D3E1; Thu, 2 Sep 2004 04:02:24 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7872C8D3DD for ; Thu, 2 Sep 2004 04:02:23 -0400 (EDT) Received: (qmail 94956 invoked by uid 3269); 2 Sep 2004 08:02:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94953 invoked from network); 2 Sep 2004 08:02:23 -0000 Received: from saturn.bt.com (HELO cbibipnt05.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 2 Sep 2004 08:02:23 -0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SABG4N45; Thu, 2 Sep 2004 09:02:29 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1094112147299; Thu, 2 Sep 2004 09:02:27 +0100 Received: from mut.jungle.bt.co.uk ([132.146.127.89]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i8282A7T022506; Thu, 2 Sep 2004 09:02:15 +0100 Message-Id: <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Sep 2004 09:03:28 +0100 To: Mark Baugher From: Bob Briscoe Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: References: <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: elisabetta.carrara@ericsson.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Mark, At 18:49 30/08/2004, Mark Baugher wrote: >Bob, > I reply to many of your points below, but here is something I'd like >for you and your co-authors to consider: Apart from reusing the RTP >timestamp field the issue you raise in point 3 is a general TESLA issue >and not an SRTP-TESLA issue. I think this is also true for guidance on >the use or non-use of a group MAC, which is related to your point 3. >I'd like to see these points treated in a general way so why not >critique the base TESLA spec on this point and not SRTP-TESLA? Yup, for the DoS prevention, Ran Canetti has proposed we need to add a more formal DoS mitigation section to TESLA-intro. This mail thread just goes to show how getting specific about a protocol (SRTP) feeds back to the generic description. It was only when we got to the specifics that the issues became clear. I'll stop pestering you for a while on point 3/ (DoS prevention). On use/non-use of group MAC, TESLA-intro won't MANDATE anything. It's informational. More inline. > More below... >On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: >... >>Having thought about it, I will be stronger than the last mail and say >>a group MAC will provide barely any additional protection in most >>circumstances so should not be the default. The logic of using a group >>MAC with TESLA looks like this: >> >> Sender's level of trust in group members not to spoof packets >> | using a group key? | >> Low High >> | | >> Use source authentication (ie TESLA). Use group >>authentication. >> | >> TESLA is vulnerable to DoS filling buffer >> until delayed auth >> | >> Use group authentication alongside TESLA >> (as in current SRTP draft) >> >>I hope this diagram helps highlight the broken logic. >>Group authentication is being MANDATED in the SRTP draft in a scenario >>which only ever arises where the group isn't trusted. > >Trusted to do or not do what? I think in this case, "trusted" means >"trusted not to launch a denial of service attack against the group." >There is also "trusted not to capture a disclosed key to successfully >impersonate a group sender." Further, there is "trusted not to >disclose a group key" - and so on. Treating something as complicated >as this as "high" or "low" is not persuading me, personally. I started out the diag making clear the trust context, but yes, it got munged into unspecified trust in the explanatory para after. SOrry. I think it best if I write all the applicability stuff into a new DoS sectino in the TESLA-intro, then we can have this debate with some clarity. I hope to do this while the issue is fresh - next few days, but... >>dding group authentication to TESLA only provides any additional value >>for the narrow range of scenarios where group members aren't trusted >>enough to use group authentication alone, but they are trusted >>sufficiently that group authentication might detect some DoS attacks - >>pretty slim odds. Worth allowing as an option, but surely not >>MANDATING. > >You see a waste of time and bandwidth for protection that is >superfluous. I see a relatively cheap way to keep a group protected >against anyone running a kiddie script who decides to send a burst of >packets and overflow members' buffers. Let's gather some more opinion >from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. The S/KEY-like scheme in point 3/ is an alternative, but it's now different to what I described following Adrian Perrig knocking it down,... me fixing it,... then Adrian agreeing it's now OK. It's now a good option for fixed or nearly-fixed packet rate (eg audio), but needs applicability carefully explaining for highly variable packet rate (eg video). I've agreed to document three DoS mitigation possibilities in a next TESLA-intro draft: * check that the disclosed key fits the chain (simple but weak - always worth doing) * group MAC * disclose & use new key each packet I think it's best to wait for that before the debate on what defaults/options/transforms there should be in SRTP-TESLA. I've split the remaining reply into separate threads for each numbered issue I raised at least those still up for debate, as requested. THey are all orthogonal. >>>>2/ Non-TESLA group authentication to protect against DoS should be >>>>optional >>>>--------------------------------------------------------------------- >>>>-- ---- >>>>The immediate authentication provided by your non-TESLA group >>>>authentication only protects against DoS by non-group members. It >>>>should be RECOMMENDED not REQUIRED (section 7). >>> >>>I think that this point should be resolved in the base TESLA >>>specification, i.e. I don't think there is anything that is >>>SRTP-specific to this point. But we did not treat it that way in >>>SRTP-TESLA, and that's probably my fault. Nonetheless, I think it >>>should be REQUIRED in base TESLA. >> >>Currently section 5 (security considerations) of the TESLA-intro >>mentions group authentication as one possible way of preventing >>flooding attacks during the key disclosure delay. But it doesn't >>MANDATE it. I'm simply taking issue with group authentication being >>MANDATED in SRTP-TESLA, as I don't think it's effective in many >>(most?) scenarios, making it unnecessary overhead. >> >>I have no problem with making a group MAC optional for scenarios where >>it does improve matters. > >I don't have a lot of religious fervor on the topic either though I >like to avoid options in security protocols whenever possible. What >seemed fairly obvious to me obviously seems wasteful to you. I'd like >to discuss this further in a separate thread. We are really discussing >a security requirement for protecting groups. >... > >> >>Sorry, history was a distracting word. I meant likelihood. Imagine a >>video conf between senior execs of competing companies, or between >>representatives of mutually distrusting governments. They don't trust >>each other not to spoof what the other parties are saying, but they >>have no likelihood of one launching a flooding attack on the other >>(e.g. the whole thing is over a joint VPN). They need group >>authentication like a phish needs a bicycle. So why MANDATE it? > >We are beating this to death and confusing one another. The >participants would not launch the flooding attack; an interloper would >do it. If it's over a VPN, then the attack seems very unlikely - as is >source spoofing in a small teleconference, for that matter. >... >> >>>relies upon the fact that memory gets tied up while >>>packets are buffered awaiting authentication. In this case, there is >>>no buffering of multiple packets, just one packet during the >>>disclosure >>>interval. Do I understand you correctly? >> >>No. The disclosure *interval* (delay) still spans multiple packets. >>The new feature depends on each key now only ever being *disclosed* >>once, rather than the same key being disclosed repeatedly as it was >>when there were multiple packets in the same TESLA time interval. > >Before we go any further into this, I'd like to understand why this >disclosure scheme needs to be considered only for SRTP. You mention >below that you also think that it belongs in the base TESLA >specification and that you have raised the issue with your co-authors? >I think the TESLA co-authors might want to consider discussing this on >the list. That sounds better than treating SRTP-TESLA as the poster >child for something that was maybe overlooked in the base TESLA >document. > >I just got back from some personal time off and am working through >several hundred messages - I prioritized yours. It would be a more >efficient discussion to discuss this with the TESLA authors - on the >msec list if possible. > >> >>As soon as a packet arrives, the disclosed key in it now has two >>purposes: >>- it's original TESLA purpose: to verify a packet received some time >>previously >>- to immediately show the receiver that the sender of this packet knew >>the next key back along the hash chain which is now only ever >>*disclosed* once >> >>So if more packets are received that *disclose* the same key, the >>receiver can assume (at least until the delayed TESLA verification) >>that only the first packet to disclose each key was genuine. >> >>If a network element is compromised, an attacker can discover the next >>disclosed key and overtake or replace a genuine packet with many >>others. But the receiver can still immediately discard all but the >>first to arrive, protecting itself from memory overflow. >> >>So the scheme has the following properties: >>- The receiver will never buffer more than one packet per packet sent >>by the genuine sender (so the receiver's buffer fill rate is still >>clocked by the party that reveals each new key backwards in the >>chain). >>- As each key is later disclosed, TESLA can do delayed verification of >>these stored packets. >> - if they pass delayed verfication, the messages must be genuine >> - if they fail delayed verfication, the messages must not have been >>genuine >>- The true message will have been lost in the latter case. But, then >>if an attacker can compromise a network element, it can discard the >>true messages anyway (a group MAC can't prevent this either ;) >> >>I need to fully document this. There are some corner cases not covered >>by the above. I've given an outline later. Obviously, this DoS >>protection idea hasn't had the same peer-review as TESLA, except it is >>essentially just S/KEY, which has had ample peer review (but perhaps >>not in a group setting). > >This sounds promising to me, but I would like to see the document - I >have not read the one you sent me yet. And I would like to hear what >the other TESLA authors have to say about it. >> > >... >>>If so, why >>>not put this in the core TESLA specification. I'd say that if it >>>belongs in SRTP-TESLA, then it belongs in the core specification. No? >> >>You are absolutely correct. >> >>We (the co-authors of the TESLA base spec) are discussing this >>off-line right now. It's my fault we didn't reach closure on it before >>TESLA got this far. I was originally pushing this as an option, but I >>think I never quite got myself understood. Somewhere in the mists of >>time I gave up. I've been taking a back seat on the TESLA work until >>just recently, so my brain obviously wasn't in gear when reviewing >>drafts. I forgot I'd got this option to attack the DoS problem. It was >>only through reveiwing the SRTP draft that the technique came back to >>me. Now, the more I argue about it, the better I think it is. >> >>However, it's not out of the woods yet. My co-authors are trying to >>break it. I believe I've defended it in the case of variable packet >>rate and packet misordering. But I'm expecting more attempts to break >>it (and, of course, anyone on this list is welcome to try as well). >> >>If it comes out intact, you should see text on it shortly. Otherwise, >>I guess the TESLA base spec will stay as it is. > >And this sizable email exchange would be in vain :?) >> > >... >>>>BTW, it should be pointed out that the verification algo should check >>>>the key index is within an expected range before using it (e.g. only >>>>a >>>>small increment above the last highest verified key index seen). >>>>Otherwise, an attacker can tamper with this field to lead all >>>>receivers to run millions of hash operations unnecessarily. I prefer >>>>to call it a key-index *hint*, to remind me not to rely on it being >>>>correct. >>> >>>This sounds like an argument for keeping the MAC. >> >>No. It is an argument for watching that it doesn't appear to imply >>packets are extremely re-ordered (e.g. it must be no more than, say, >>64 different from the previous highest index, cf the SRTP replay >>protection window). You /could/ use a group MAC to do an initial test >>of its integrity, but why waste 10 octets when you can do a test that >>uses none? And this would only work if you trusted the group members >>(recall, we are using TESLA because we don't trust them). > >The group MAC was originally 4 bytes and I need to check with >Elisabetta to find out why it is now 10. I don't see why it needs to >be larger than 4 bytes for group MAC purposes. If we manage to obviate >the need for group MACs in TESLA, then it can be zero bytes and I'll be >perfectly happy. >> >>The key index is implicitly authenticated (similar to the implicit >>header authentication in section 9.5.2 of the SRTP RFC) because the >>TESLA MAC depends on it. If the key index is tampered with, the >>authentication test will fail as it should. > >Ok. >> >... >>> >>>We'll refer to your editorial comments at the next revision. >> >>I've added a couple more below... > >Good. How do you feel about my proposal to consider the proposed use >of the RTP timestamp field separately from the group MAC. And treat >the group MAC as a related question to your point 3 scheme? Yup. Done. Cheers Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 2 04:14:11 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11652 for ; Thu, 2 Sep 2004 04:14:11 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 55D2C8D3ED; Thu, 2 Sep 2004 04:14:12 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 45EA28D382 for ; Thu, 2 Sep 2004 04:14:11 -0400 (EDT) Received: (qmail 97315 invoked by uid 3269); 2 Sep 2004 08:14:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97312 invoked from network); 2 Sep 2004 08:14:11 -0000 Received: from saturn.bt.com (HELO cbibipnt05.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 2 Sep 2004 08:14:11 -0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SABG44XR; Thu, 2 Sep 2004 09:14:17 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1094112856378; Thu, 2 Sep 2004 09:14:16 +0100 Received: from mut.jungle.bt.co.uk ([132.146.127.89]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i828E17T022566; Thu, 2 Sep 2004 09:14:06 +0100 Message-Id: <5.2.1.1.2.20040902085428.019f1ce8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Sep 2004 09:15:19 +0100 To: Mark Baugher From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: elisabetta.carrara@ericsson.com, msec@securemulticast.org Subject: [MSEC] Key index field is redundant with SRTP X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Mark, This is issue 1/ split out from the long thread reviewing draft-ietf-msec-srtp-tesla-01.txt more inline... >>>>The key index can be derived from the RTP timestamp in each message. >>>>This saves 4 bytes in each packet. >>> >>>I would not say that two fields are redundant if they perform different >>>functions, which I think is the case here. We would need to do a >>>complete analysis of how the timestamp is used today in RTP >>>applications before we can evaluate how safe this would be for all >>>applications. I'd prefer to not overload an existing field in this way >>>if we can avoid it. >> >>I had thought about the ramifications fairly carefully before saying >>this. I suggest that the way to deal with the TESLA time interval >>identifier, I, is to: >>- remove I from the default TESLA-SRTP packet format >>- explain how to derive I from the RTP timestamp > >I may have confused you in my last note in trying to explain all the >ways that I think overloading protocol fields for security purposes is >generally not a good idea. Let me try to state this clearly: The RTP >timestamp is used for specific purposes for RTP payload types that are >unrelated to sender authentication, and it is quite possible that we >will either interfere with these uses by placing TESLA-induced >constraints on that field or weaken TESLA security when we find >surprising uses are made of that field by certain applications. > >Re-use of the RTP Timestamp in TESLA can be easily avoided by adding a >TESLA timetamp field in the packet. I think the points you are raising >are important and helpful to SRTP-TESLA. But it would helpful if you >separated them I think. >Re-use of the RTP timestamp, the non-mandatory >group MAC, and your proposal under point 3 can stand by themselves. I >think we have 3 threads here and not one. > >>- MANDATE that a sender authentication module should use a TESLA key >>interval derived from the RTP timestamp, not the clock >>- warn implementors that any delay in the sender stack will add to the >>TESLA authentication delay (but not weaken it) >>- (if we can think of any other problems ) warn implementors what to >>watch out for when overloading the RTP timestamp function (I'm fairly >>sure there aren't any - and I've thought long and hard) > >I'd prefer to use a separate field. At minimum, I would take this to >AVT for further discussion. I don't think the gain from overloading is >worth any unexpected pitfalls, particularly security pitfalls. RTP is >a special beast because it is used in so many types of applications, >from telephony to client/server multimedia, from unicast-pairwise to >unicast-group, small multicast conferences to large-scale broadcast, >etc. Certainly put it to AVT. >>- make I optional in the TESLA-SRTP packet format for implementors to >>use if they are in one of these obscure scenarios ...despite what I said above, I wholly support trying to avoid options. Perhaps if someone comes up with an odd use of the RTP timestamp, it's up to them to work round the standard by changing the layering in their implementation. I'd rather we don't add more packet size for hypothetical odd uses of the timestamp, unless someone comes up with a concrete one they can't work round. >>>>If the sender buffers packets between adding the RTP timestamp and >>>>adding TESLA authentication fields, this will add to the TESLA >>>>authentication delay. But a good RTP implementation shouldn't be >>>>doing >>>>serious buffering here. >>> >>>What about high-bandwidth, server/playback media such as movies? In >>>fact, let me try this: What about an MPEG packetizer that does a lot >>>of pre-processing of the MPEG AUs prior to assigning them to packets. >>>This might happen because the AUs were encrypted and required a lot of >>>pre-processing. Maybe there would be a two-step process applied to >>>one >>>or more AUs in which timetamps are assigned during some processing and >>>then everything gets sent. >>>Maybe such a problem can be avoided in packetizers. There are a lot >>>of >>>considerations when we take an existing field such as the RTP >>>timestamp >>>and add new functions to it. >> >>As long as we mandate that the TESLA sender uses the key appropriate >>to the time interval derived from the RTP timestamp (not from the >>clock), the protocol is safe. The TESLA safety test is still accurate. >> >>Any delay after RTP has determined its timestamp then folds into the >>delay between sender and receiver that TESLA is designed to handle >>safely. Of course, this makes the delay longer, which /delays/ >>authentication. But it doesn't /weaken/ authentication. See section 4 >>of the TESLA intro for discussion of similar scenarios (eg TCP >>buffering). >> >>If authentication delay is a problem for a particular scenario, and >>it's some odd scenario like you suggest where a large part of the >>delay is within the sender stack between RTP and TESLA, then the >>implementor can choose to use an explicit I in the packet. > >TESLA is complex enough without adding protocol dependencies like this >in my view. > >> >>>If the functions are really identical, then they are redundant. I >>>tend >>>to doubt that. >> >>I'd rather say that the functions of the two fields are invariably >>equivalent, but may not be in some scenarios, when it's up to the >>implementor to use the option of an explicit I. > >This new option will double the signaling, implementation, testing, and >operational complexity of the protocol. Understood Cheers Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 2 11:01:20 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10465 for ; Thu, 2 Sep 2004 11:01:19 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D04838C1B4; Thu, 2 Sep 2004 11:01:20 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D6A378C1CE for ; Thu, 2 Sep 2004 11:01:18 -0400 (EDT) Received: (qmail 68708 invoked by uid 3269); 2 Sep 2004 15:01:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68699 invoked from network); 2 Sep 2004 15:01:18 -0000 Received: from saturn.bt.com (HELO cbibipnt05.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 2 Sep 2004 15:01:18 -0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SABG57XS; Thu, 2 Sep 2004 16:01:23 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1094137282456; Thu, 2 Sep 2004 16:01:22 +0100 Received: from mut.jungle.bt.co.uk ([132.146.127.89]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i82F137T026961; Thu, 2 Sep 2004 16:01:10 +0100 Message-Id: <5.2.1.1.2.20040902154950.02341948@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Sep 2004 16:02:21 +0100 To: "Elisabetta Carrara (KI/EAB)" From: Bob Briscoe Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BC3C4@Esealnt877.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Atul.Sharma@nokia.com, mbaugher@cisco.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Elisabetta, At 08:18 02/09/2004, Elisabetta Carrara (KI/EAB) wrote: > >The group MAC is default 4 bytes in the SRTP-TESLA draft. >Please point me out if any text in the draft says differently. > >/E You're right. I looked in the table of default values in section 6.1 and not finding it, I went to the SRTP RFC where it says 80 bits. I missed the sentence in section 6 saying truncate it to 32 bits. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 10 10:50:57 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03443 for ; Fri, 10 Sep 2004 10:50:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B591E8D64F; Fri, 10 Sep 2004 10:50:57 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DA8858C9C0 for ; Fri, 10 Sep 2004 10:50:56 -0400 (EDT) Received: (qmail 1810 invoked by uid 3269); 10 Sep 2004 14:50:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1805 invoked from network); 10 Sep 2004 14:50:56 -0000 Received: from smtp20.libero.it (193.70.192.147) by klesh.pair.com with SMTP; 10 Sep 2004 14:50:56 -0000 Received: from localhost (172.16.1.80) by smtp20.libero.it (7.0.027-DD01) id 40E3F8E700C620D0 for msec@securemulticast.org; Fri, 10 Sep 2004 16:50:55 +0200 Received: from libero.it (151.28.187.188) by smtp20.libero.it (7.0.027-DD01) id 40E3F8E202D07295 for msec@securemulticast.org; Fri, 10 Sep 2004 16:50:55 +0200 Message-ID: <4141BF48.9010902@libero.it> Date: Fri, 10 Sep 2004 16:50:48 +0200 From: Margherita Rizzo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at libero.it Subject: [MSEC] a question about keys X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi, I have a question about security multicast communications in the case of one sender and many receivers. I am searching for a solution of this kind: let's suppose a simple case of a sender and a small number of receivers, for example 3; the sender uses a key K for encrypting data that delivers to the three receivers. Is it possible for them to use three different keys, for example K1, K2, K3 for decripting what they receive? Or, in other words, is it possible to assign three diffeent keys for decripting and then, using some function, to create a unique key for encripting data in such a manner that it could decrypted by three receivers? Thank you _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 10 11:11:55 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05114 for ; Fri, 10 Sep 2004 11:11:55 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6B17B8D475; Fri, 10 Sep 2004 11:11:57 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 84FD98D44A for ; Fri, 10 Sep 2004 11:11:55 -0400 (EDT) Received: (qmail 5573 invoked by uid 3269); 10 Sep 2004 15:11:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5570 invoked from network); 10 Sep 2004 15:11:55 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 10 Sep 2004 15:11:55 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Sep 2004 08:20:06 -0700 Received: from [192.168.0.10] (sjc-vpn5-907.cisco.com [10.21.91.139]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8AFBqwW005593; Fri, 10 Sep 2004 08:11:52 -0700 (PDT) In-Reply-To: <4141BF48.9010902@libero.it> References: <4141BF48.9010902@libero.it> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] a question about keys Date: Fri, 10 Sep 2004 08:11:42 -0700 To: Margherita Rizzo X-Mailer: Apple Mail (2.619) Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit hi Margherita, You should do a search using Google and feed in the phrase "traitor tracing" or other phrases that have the word "traitor" in the context of group security. See, for example, http://crypto.stanford.edu/~dabo/abstracts/traitors.html Best regards, Mark On Sep 10, 2004, at 7:50 AM, Margherita Rizzo wrote: > Hi, > I have a question about security multicast communications in the case > of one sender and many receivers. > I am searching for a solution of this kind: let's suppose a simple > case of a sender and a small number of receivers, for example 3; the > sender uses a key K for encrypting data that delivers to the three > receivers. Is it possible for them to use three different keys, for > example K1, K2, K3 for decripting what they receive? > Or, in other words, is it possible to assign three diffeent keys for > decripting and then, using some function, to create a unique key for > encripting data in such a manner that it could decrypted by three > receivers? > Thank you > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 10 11:17:54 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05664 for ; Fri, 10 Sep 2004 11:17:53 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 424618D4CE; Fri, 10 Sep 2004 11:17:55 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 728E48D482 for ; Fri, 10 Sep 2004 11:17:54 -0400 (EDT) Received: (qmail 7157 invoked by uid 3269); 10 Sep 2004 15:17:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7154 invoked from network); 10 Sep 2004 15:17:54 -0000 Received: from mailman.core.ipp.pt (193.136.60.12) by klesh.pair.com with SMTP; 10 Sep 2004 15:17:54 -0000 Received: (qmail 12621 invoked by uid 0); 10 Sep 2004 15:13:22 -0000 Received: from unknown (HELO port3) (195.22.30.139) by mailman.core.ipp.pt with SMTP; 10 Sep 2004 15:13:22 -0000 From: =?iso-8859-1?Q?Ant=F3nio_Pinto?= To: Date: Fri, 10 Sep 2004 16:18:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcSXSV8VjZ/XK1jURrO+snKpL47kfw== Message-Id: <20040910151754.728E48D482@six.pairlist.net> Subject: [MSEC] Software implementation X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi, Do you know if there is anyone developing software based on the MSEC architecture? It may be a little early for this, considering that not all standards are completed. But I would like to do some work in this area. I am a Java / C++ / C network programmer with little experience, but with great interest in secure multicast (for academic reasons). Antonio Pinto _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 10 13:35:43 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16042 for ; Fri, 10 Sep 2004 13:35:42 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 642088CB92; Fri, 10 Sep 2004 13:35:42 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6ABA18C68C for ; Fri, 10 Sep 2004 13:35:41 -0400 (EDT) Received: (qmail 34338 invoked by uid 3269); 10 Sep 2004 17:35:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34335 invoked from network); 10 Sep 2004 17:35:41 -0000 Received: from smtp2.libero.it (193.70.192.52) by klesh.pair.com with SMTP; 10 Sep 2004 17:35:41 -0000 Received: from localhost (172.16.1.84) by smtp2.libero.it (7.0.027-DD01) id 40C734760124784F for msec@securemulticast.org; Fri, 10 Sep 2004 19:35:52 +0200 Received: from libero.it (172.16.1.103) by smtp2.libero.it (7.0.027-DD01) id 40C734700085EC1F for msec@securemulticast.org; Fri, 10 Sep 2004 19:35:52 +0200 Date: Fri, 10 Sep 2004 19:35:39 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "Marg" To: "msec" X-XaM3-API-Version: 4.1 (B27) X-type: 0 X-SenderIP: 193.204.86.136 X-Virus-Scanned: by amavisd-new at libero.it Subject: [MSEC] code for traitor tracing X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hi, I need the code of TA algorithm for traitor tracing for scientific s= tudy. Do you know where i can find it? _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Sep 12 19:28:54 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19916 for ; Sun, 12 Sep 2004 19:28:51 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7E1178D2D3; Sun, 12 Sep 2004 19:28:51 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BD1CC8D15E for ; Sun, 12 Sep 2004 19:28:50 -0400 (EDT) Received: (qmail 94124 invoked by uid 3269); 12 Sep 2004 23:28:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94120 invoked from network); 12 Sep 2004 23:28:50 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 12 Sep 2004 23:28:50 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Sep 2004 16:29:10 -0700 X-BrightmailFiltered: true Received: from [192.168.0.11] (sjc-vpn2-1468.cisco.com [10.21.117.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8CNSkxk001451; Sun, 12 Sep 2004 16:28:47 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Sun, 12 Sep 2004 15:49:19 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: elisabetta.carrara@ericsson.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit hi Bob Just to recap this thread: We agreed to make the group MAC a RECOMMENDED feature rather than required. We'll use you editorial comments as a guide when we make the next update to the specification. And we'll look forward to reviewing DoS points in a subsequent revision of the base TESLA I-D. thanks, Mark On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote: > Mark, > > At 18:49 30/08/2004, Mark Baugher wrote: >> Bob, >> I reply to many of your points below, but here is something I'd like >> for you and your co-authors to consider: Apart from reusing the RTP >> timestamp field the issue you raise in point 3 is a general TESLA >> issue >> and not an SRTP-TESLA issue. I think this is also true for guidance >> on >> the use or non-use of a group MAC, which is related to your point 3. >> I'd like to see these points treated in a general way so why not >> critique the base TESLA spec on this point and not SRTP-TESLA? > > Yup, for the DoS prevention, Ran Canetti has proposed we need to add a > more formal DoS mitigation section to TESLA-intro. > > This mail thread just goes to show how getting specific about a > protocol (SRTP) feeds back to the generic description. It was only > when we got to the specifics that the issues became clear. I'll stop > pestering you for a while on point 3/ (DoS prevention). > > On use/non-use of group MAC, TESLA-intro won't MANDATE anything. It's > informational. > > More inline. > >> More below... >> On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: >> ... >>> Having thought about it, I will be stronger than the last mail and >>> say >>> a group MAC will provide barely any additional protection in most >>> circumstances so should not be the default. The logic of using a >>> group >>> MAC with TESLA looks like this: >>> >>> Sender's level of trust in group members not to spoof packets >>> | using a group key? | >>> Low High >>> | | >>> Use source authentication (ie TESLA). Use group >>> authentication. >>> | >>> TESLA is vulnerable to DoS filling buffer >>> until delayed auth >>> | >>> Use group authentication alongside TESLA >>> (as in current SRTP draft) >>> >>> I hope this diagram helps highlight the broken logic. >>> Group authentication is being MANDATED in the SRTP draft in a >>> scenario >>> which only ever arises where the group isn't trusted. >> >> Trusted to do or not do what? I think in this case, "trusted" means >> "trusted not to launch a denial of service attack against the group." >> There is also "trusted not to capture a disclosed key to successfully >> impersonate a group sender." Further, there is "trusted not to >> disclose a group key" - and so on. Treating something as complicated >> as this as "high" or "low" is not persuading me, personally. > > I started out the diag making clear the trust context, but yes, it got > munged into unspecified trust in the explanatory para after. SOrry. I > think it best if I write all the applicability stuff into a new DoS > sectino in the TESLA-intro, then we can have this debate with some > clarity. > > I hope to do this while the issue is fresh - next few days, but... > > >>> dding group authentication to TESLA only provides any additional >>> value >>> for the narrow range of scenarios where group members aren't trusted >>> enough to use group authentication alone, but they are trusted >>> sufficiently that group authentication might detect some DoS attacks >>> - >>> pretty slim odds. Worth allowing as an option, but surely not >>> MANDATING. >> >> You see a waste of time and bandwidth for protection that is >> superfluous. I see a relatively cheap way to keep a group protected >> against anyone running a kiddie script who decides to send a burst of >> packets and overflow members' buffers. Let's gather some more opinion >> from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. > > The S/KEY-like scheme in point 3/ is an alternative, but it's now > different to what I described following Adrian Perrig knocking it > down,... me fixing it,... then Adrian agreeing it's now OK. It's now a > good option for fixed or nearly-fixed packet rate (eg audio), but > needs applicability carefully explaining for highly variable packet > rate (eg video). > > I've agreed to document three DoS mitigation possibilities in a next > TESLA-intro draft: > * check that the disclosed key fits the chain (simple but weak - > always worth doing) > * group MAC > * disclose & use new key each packet > > I think it's best to wait for that before the debate on what > defaults/options/transforms there should be in SRTP-TESLA. > > I've split the remaining reply into separate threads for each numbered > issue I raised at least those still up for debate, as requested. THey > are all orthogonal. > > > >>>>> 2/ Non-TESLA group authentication to protect against DoS should be >>>>> optional >>>>> ------------------------------------------------------------------- >>>>> -- -- ---- >>>>> The immediate authentication provided by your non-TESLA group >>>>> authentication only protects against DoS by non-group members. It >>>>> should be RECOMMENDED not REQUIRED (section 7). >>>> >>>> I think that this point should be resolved in the base TESLA >>>> specification, i.e. I don't think there is anything that is >>>> SRTP-specific to this point. But we did not treat it that way in >>>> SRTP-TESLA, and that's probably my fault. Nonetheless, I think it >>>> should be REQUIRED in base TESLA. >>> >>> Currently section 5 (security considerations) of the TESLA-intro >>> mentions group authentication as one possible way of preventing >>> flooding attacks during the key disclosure delay. But it doesn't >>> MANDATE it. I'm simply taking issue with group authentication being >>> MANDATED in SRTP-TESLA, as I don't think it's effective in many >>> (most?) scenarios, making it unnecessary overhead. >>> >>> I have no problem with making a group MAC optional for scenarios >>> where >>> it does improve matters. >> >> I don't have a lot of religious fervor on the topic either though I >> like to avoid options in security protocols whenever possible. What >> seemed fairly obvious to me obviously seems wasteful to you. I'd like >> to discuss this further in a separate thread. We are really >> discussing >> a security requirement for protecting groups. >> ... >> >>> >>> Sorry, history was a distracting word. I meant likelihood. Imagine a >>> video conf between senior execs of competing companies, or between >>> representatives of mutually distrusting governments. They don't trust >>> each other not to spoof what the other parties are saying, but they >>> have no likelihood of one launching a flooding attack on the other >>> (e.g. the whole thing is over a joint VPN). They need group >>> authentication like a phish needs a bicycle. So why MANDATE it? >> >> We are beating this to death and confusing one another. The >> participants would not launch the flooding attack; an interloper would >> do it. If it's over a VPN, then the attack seems very unlikely - as >> is >> source spoofing in a small teleconference, for that matter. >> ... >>> >>>> relies upon the fact that memory gets tied up while >>>> packets are buffered awaiting authentication. In this case, there >>>> is >>>> no buffering of multiple packets, just one packet during the >>>> disclosure >>>> interval. Do I understand you correctly? >>> >>> No. The disclosure *interval* (delay) still spans multiple packets. >>> The new feature depends on each key now only ever being *disclosed* >>> once, rather than the same key being disclosed repeatedly as it was >>> when there were multiple packets in the same TESLA time interval. >> >> Before we go any further into this, I'd like to understand why this >> disclosure scheme needs to be considered only for SRTP. You mention >> below that you also think that it belongs in the base TESLA >> specification and that you have raised the issue with your co-authors? >> I think the TESLA co-authors might want to consider discussing this on >> the list. That sounds better than treating SRTP-TESLA as the poster >> child for something that was maybe overlooked in the base TESLA >> document. >> >> I just got back from some personal time off and am working through >> several hundred messages - I prioritized yours. It would be a more >> efficient discussion to discuss this with the TESLA authors - on the >> msec list if possible. >> >>> >>> As soon as a packet arrives, the disclosed key in it now has two >>> purposes: >>> - it's original TESLA purpose: to verify a packet received some time >>> previously >>> - to immediately show the receiver that the sender of this packet >>> knew >>> the next key back along the hash chain which is now only ever >>> *disclosed* once >>> >>> So if more packets are received that *disclose* the same key, the >>> receiver can assume (at least until the delayed TESLA verification) >>> that only the first packet to disclose each key was genuine. >>> >>> If a network element is compromised, an attacker can discover the >>> next >>> disclosed key and overtake or replace a genuine packet with many >>> others. But the receiver can still immediately discard all but the >>> first to arrive, protecting itself from memory overflow. >>> >>> So the scheme has the following properties: >>> - The receiver will never buffer more than one packet per packet sent >>> by the genuine sender (so the receiver's buffer fill rate is still >>> clocked by the party that reveals each new key backwards in the >>> chain). >>> - As each key is later disclosed, TESLA can do delayed verification >>> of >>> these stored packets. >>> - if they pass delayed verfication, the messages must be genuine >>> - if they fail delayed verfication, the messages must not have been >>> genuine >>> - The true message will have been lost in the latter case. But, then >>> if an attacker can compromise a network element, it can discard the >>> true messages anyway (a group MAC can't prevent this either ;) >>> >>> I need to fully document this. There are some corner cases not >>> covered >>> by the above. I've given an outline later. Obviously, this DoS >>> protection idea hasn't had the same peer-review as TESLA, except it >>> is >>> essentially just S/KEY, which has had ample peer review (but perhaps >>> not in a group setting). >> >> This sounds promising to me, but I would like to see the document - I >> have not read the one you sent me yet. And I would like to hear what >> the other TESLA authors have to say about it. >>> >> >> ... >>>> If so, why >>>> not put this in the core TESLA specification. I'd say that if it >>>> belongs in SRTP-TESLA, then it belongs in the core specification. >>>> No? >>> >>> You are absolutely correct. >>> >>> We (the co-authors of the TESLA base spec) are discussing this >>> off-line right now. It's my fault we didn't reach closure on it >>> before >>> TESLA got this far. I was originally pushing this as an option, but I >>> think I never quite got myself understood. Somewhere in the mists of >>> time I gave up. I've been taking a back seat on the TESLA work until >>> just recently, so my brain obviously wasn't in gear when reviewing >>> drafts. I forgot I'd got this option to attack the DoS problem. It >>> was >>> only through reveiwing the SRTP draft that the technique came back to >>> me. Now, the more I argue about it, the better I think it is. >>> >>> However, it's not out of the woods yet. My co-authors are trying to >>> break it. I believe I've defended it in the case of variable packet >>> rate and packet misordering. But I'm expecting more attempts to break >>> it (and, of course, anyone on this list is welcome to try as well). >>> >>> If it comes out intact, you should see text on it shortly. Otherwise, >>> I guess the TESLA base spec will stay as it is. >> >> And this sizable email exchange would be in vain :?) >>> >> >> ... >>>>> BTW, it should be pointed out that the verification algo should >>>>> check >>>>> the key index is within an expected range before using it (e.g. >>>>> only >>>>> a >>>>> small increment above the last highest verified key index seen). >>>>> Otherwise, an attacker can tamper with this field to lead all >>>>> receivers to run millions of hash operations unnecessarily. I >>>>> prefer >>>>> to call it a key-index *hint*, to remind me not to rely on it being >>>>> correct. >>>> >>>> This sounds like an argument for keeping the MAC. >>> >>> No. It is an argument for watching that it doesn't appear to imply >>> packets are extremely re-ordered (e.g. it must be no more than, say, >>> 64 different from the previous highest index, cf the SRTP replay >>> protection window). You /could/ use a group MAC to do an initial test >>> of its integrity, but why waste 10 octets when you can do a test that >>> uses none? And this would only work if you trusted the group members >>> (recall, we are using TESLA because we don't trust them). >> >> The group MAC was originally 4 bytes and I need to check with >> Elisabetta to find out why it is now 10. I don't see why it needs to >> be larger than 4 bytes for group MAC purposes. If we manage to >> obviate >> the need for group MACs in TESLA, then it can be zero bytes and I'll >> be >> perfectly happy. >>> >>> The key index is implicitly authenticated (similar to the implicit >>> header authentication in section 9.5.2 of the SRTP RFC) because the >>> TESLA MAC depends on it. If the key index is tampered with, the >>> authentication test will fail as it should. >> >> Ok. >>> >> ... >>>> >>>> We'll refer to your editorial comments at the next revision. >>> >>> I've added a couple more below... >> >> Good. How do you feel about my proposal to consider the proposed use >> of the RTP timestamp field separately from the group MAC. And treat >> the group MAC as a related question to your point 3 scheme? > > Yup. Done. > > Cheers > > > Bob > > > _______________________________________________________________________ > _____ > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Sep 12 19:29:01 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19941 for ; Sun, 12 Sep 2004 19:29:01 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A1CDA8D371; Sun, 12 Sep 2004 19:28:56 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C4A528D36C for ; Sun, 12 Sep 2004 19:28:55 -0400 (EDT) Received: (qmail 94138 invoked by uid 3269); 12 Sep 2004 23:28:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94135 invoked from network); 12 Sep 2004 23:28:55 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 12 Sep 2004 23:28:55 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 12 Sep 2004 16:30:51 -0700 X-BrightmailFiltered: true Received: from [192.168.0.11] (sjc-vpn2-1468.cisco.com [10.21.117.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8CNSkxn001451; Sun, 12 Sep 2004 16:28:53 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20040902085428.019f1ce8@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040902085428.019f1ce8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B65887B-050E-11D9-9416-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Key index field is redundant with SRTP Date: Sun, 12 Sep 2004 15:52:27 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: elisabetta.carrara@ericsson.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit hi Bob, Do you still think we should use the RTP timestamp in place of the key ID? Mark On Sep 2, 2004, at 1:15 AM, Bob Briscoe wrote: > Mark, > > This is issue 1/ split out from the long thread reviewing > draft-ietf-msec-srtp-tesla-01.txt > > more inline... > >>>>> The key index can be derived from the RTP timestamp in each >>>>> message. >>>>> This saves 4 bytes in each packet. >>>> >>>> I would not say that two fields are redundant if they perform >>>> different >>>> functions, which I think is the case here. We would need to do a >>>> complete analysis of how the timestamp is used today in RTP >>>> applications before we can evaluate how safe this would be for all >>>> applications. I'd prefer to not overload an existing field in this >>>> way >>>> if we can avoid it. >>> >>> I had thought about the ramifications fairly carefully before saying >>> this. I suggest that the way to deal with the TESLA time interval >>> identifier, I, is to: >>> - remove I from the default TESLA-SRTP packet format >>> - explain how to derive I from the RTP timestamp >> >> I may have confused you in my last note in trying to explain all the >> ways that I think overloading protocol fields for security purposes is >> generally not a good idea. Let me try to state this clearly: The RTP >> timestamp is used for specific purposes for RTP payload types that are >> unrelated to sender authentication, and it is quite possible that we >> will either interfere with these uses by placing TESLA-induced >> constraints on that field or weaken TESLA security when we find >> surprising uses are made of that field by certain applications. >> >> Re-use of the RTP Timestamp in TESLA can be easily avoided by adding a >> TESLA timetamp field in the packet. I think the points you are >> raising >> are important and helpful to SRTP-TESLA. But it would helpful if you >> separated them I think. >> Re-use of the RTP timestamp, the non-mandatory >> group MAC, and your proposal under point 3 can stand by themselves. I >> think we have 3 threads here and not one. >> >>> - MANDATE that a sender authentication module should use a TESLA key >>> interval derived from the RTP timestamp, not the clock >>> - warn implementors that any delay in the sender stack will add to >>> the >>> TESLA authentication delay (but not weaken it) >>> - (if we can think of any other problems ) warn implementors what to >>> watch out for when overloading the RTP timestamp function (I'm fairly >>> sure there aren't any - and I've thought long and hard) >> >> I'd prefer to use a separate field. At minimum, I would take this to >> AVT for further discussion. I don't think the gain from overloading >> is >> worth any unexpected pitfalls, particularly security pitfalls. RTP is >> a special beast because it is used in so many types of applications, >> from telephony to client/server multimedia, from unicast-pairwise to >> unicast-group, small multicast conferences to large-scale broadcast, >> etc. > > Certainly put it to AVT. > > >>> - make I optional in the TESLA-SRTP packet format for implementors to >>> use if they are in one of these obscure scenarios > > ...despite what I said above, I wholly support trying to avoid > options. Perhaps if someone comes up with an odd use of the RTP > timestamp, it's up to them to work round the standard by changing the > layering in their implementation. I'd rather we don't add more packet > size for hypothetical odd uses of the timestamp, unless someone comes > up with a concrete one they can't work round. > > >>>>> If the sender buffers packets between adding the RTP timestamp and >>>>> adding TESLA authentication fields, this will add to the TESLA >>>>> authentication delay. But a good RTP implementation shouldn't be >>>>> doing >>>>> serious buffering here. >>>> >>>> What about high-bandwidth, server/playback media such as movies? In >>>> fact, let me try this: What about an MPEG packetizer that does a >>>> lot >>>> of pre-processing of the MPEG AUs prior to assigning them to >>>> packets. >>>> This might happen because the AUs were encrypted and required a lot >>>> of >>>> pre-processing. Maybe there would be a two-step process applied to >>>> one >>>> or more AUs in which timetamps are assigned during some processing >>>> and >>>> then everything gets sent. >>>> Maybe such a problem can be avoided in packetizers. There are a lot >>>> of >>>> considerations when we take an existing field such as the RTP >>>> timestamp >>>> and add new functions to it. >>> >>> As long as we mandate that the TESLA sender uses the key appropriate >>> to the time interval derived from the RTP timestamp (not from the >>> clock), the protocol is safe. The TESLA safety test is still >>> accurate. >>> >>> Any delay after RTP has determined its timestamp then folds into the >>> delay between sender and receiver that TESLA is designed to handle >>> safely. Of course, this makes the delay longer, which /delays/ >>> authentication. But it doesn't /weaken/ authentication. See section 4 >>> of the TESLA intro for discussion of similar scenarios (eg TCP >>> buffering). >>> >>> If authentication delay is a problem for a particular scenario, and >>> it's some odd scenario like you suggest where a large part of the >>> delay is within the sender stack between RTP and TESLA, then the >>> implementor can choose to use an explicit I in the packet. >> >> TESLA is complex enough without adding protocol dependencies like this >> in my view. >> >>> >>>> If the functions are really identical, then they are redundant. I >>>> tend >>>> to doubt that. >>> >>> I'd rather say that the functions of the two fields are invariably >>> equivalent, but may not be in some scenarios, when it's up to the >>> implementor to use the option of an explicit I. >> >> This new option will double the signaling, implementation, testing, >> and >> operational complexity of the protocol. > > Understood > > > Cheers > > Bob > > _______________________________________________________________________ > _____ > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT > plc. > _______________________________________________________________________ > _____ > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 12:12:22 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21283 for ; Tue, 14 Sep 2004 12:12:22 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7F8308D252; Tue, 14 Sep 2004 12:11:29 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D8A558D244 for ; Tue, 14 Sep 2004 12:11:27 -0400 (EDT) Received: (qmail 84409 invoked by uid 3269); 14 Sep 2004 16:11:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84406 invoked from network); 14 Sep 2004 16:11:27 -0000 Received: from saturn.bt.com (HELO cbibipnt05.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 14 Sep 2004 16:11:27 -0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SABLMR0X; Tue, 14 Sep 2004 17:11:39 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1095178294549; Tue, 14 Sep 2004 17:11:34 +0100 Received: from mut.jungle.bt.co.uk (maat.jungle.bt.co.uk [132.146.108.145]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i8EGBHP3025150; Tue, 14 Sep 2004 17:11:18 +0100 Message-Id: <5.2.1.1.2.20040914165121.028d5eb0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 14 Sep 2004 17:12:47 +0100 To: canetti From: Bob Briscoe Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: References: <2C0FDBFB-FABF-11D8-A596-000A95DC10F2@cisco.com> <2C0FDBFB-FABF-11D8-A596-000A95DC10F2@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Mark Baugher , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Ran, At 05:14 31/08/2004, canetti wrote: >2. I think that Bob's idea of having the receiver infer the interval >number from the RTP timestamp may work in some/many cases. But it might >make the programming more delicate and harder to get right. One potential >solution is just to opt for a more robust design at the price of extra 4 >bytes p.p. altenratively, we can make the interval number optional and >leave it up to the implementation whether it wants to save the extra 4 >bytes or not. 1/ It's really not delicate or hard... Just like when on reception, the earliest slot the sender can be in is computed based on packet arrival time, t_j (in TESLA-intro section 3.5): floor[(t_j - T_0)/T_int = K_i] The slot K_s that the sender appears to have been in when it sent the packet can be computed based on RTP timestamp, t_s: floor[(t_s - T_0)/T_int = K_s] If there's significant delay in the sender stack after the RTP timestamp is applied, that doesn't change the security; it can just all be put down as extra network delay (but avoidable by more careful implementation). 2/ Just to emphasise a point that Adrian Perrig reminded me of when we met (offline) recently.... This use of the RTP timestamp (just like use of the key index) must not be assumed to say anything authentic about the time the packet was sent until after the packet is authenticated. It is merely a hint as to which key to try in order to see whether the packet is authentic. Then, only if the key the timestamps hints at does indeed create a matching MAC to that in the packet, can one say that the timestamp (or key index) was indeed authentic. This is implicit authentication - because correct authentication depended on it. So, we must still have the timeslot plan for the whole key chain signed in advance under an asymmetric key. The timestamps or key indices in the packets are NOT authentic until proven so by implicit authentication. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 12:37:52 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23535 for ; Tue, 14 Sep 2004 12:37:52 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 52F2E8CBF5; Tue, 14 Sep 2004 12:37:54 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BF84D8CBC7 for ; Tue, 14 Sep 2004 12:37:52 -0400 (EDT) Received: (qmail 90335 invoked by uid 3269); 14 Sep 2004 16:37:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90332 invoked from network); 14 Sep 2004 16:37:52 -0000 Received: from saturn.bt.com (HELO cbibipnt08.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 14 Sep 2004 16:37:52 -0000 Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RRCZK6FL; Tue, 14 Sep 2004 17:38:01 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a); id 109517988147; Tue, 14 Sep 2004 17:38:01 +0100 Received: from mut.jungle.bt.co.uk (maat.jungle.bt.co.uk [132.146.108.145]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i8EGbmP3025403; Tue, 14 Sep 2004 17:37:51 +0100 Message-Id: <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 14 Sep 2004 17:37:20 +0100 To: "Elisabetta Carrara (KI/EAB)" From: Bob Briscoe Subject: Fwd: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: canetti , Mark Baugher , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Elisabetta, Just made the mistake of sending before reading (I just read your 31 Aug 04= =20 posting on msec)... You make it clear that the RTP timestamp isn't as reliable as I thought. Is= =20 this possible by design, or just due to some crap implementations? So, I guess the advice should be to add a key index field unless the=20 implementor is sure of the reliability of the RTP timestamp. If this=20 assurance is going to be rare, it's a good argument for not allowing any=20 option, and always mandating the addition of a key index field... ...However, I'm wary of forcing 32 redundant bits per packet just because=20 another code module is often flakey. THat's more an argument for fixing the= =20 flakey code, not adding bloat to allow for flakiness elsewhere. It's not=20 unreasonable to expect that adding time-dependent security to an RTP=20 implementation will require tightening up pre-existing timestamping code. Of course, there might be a problem if you don't have access to someone=20 else's RTP source that you depend on. But is this really a likely scenario? Bob >Date: Tue, 14 Sep 2004 17:12:47 +0100 >To: canetti >From: Bob Briscoe >Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) >Cc: Mark Baugher , msec@securemulticast.org >Bcc: =83\Charging\Security\IN msec > >Ran, > >At 05:14 31/08/2004, canetti wrote: >>2. I think that Bob's idea of having the receiver infer the interval >>number from the RTP timestamp may work in some/many cases. But it might >>make the programming more delicate and harder to get right. One potential >>solution is just to opt for a more robust design at the price of extra 4 >>bytes p.p. altenratively, we can make the interval number optional and >>leave it up to the implementation whether it wants to save the extra 4 >>bytes or not. > >1/ It's really not delicate or hard... > >Just like when on reception, the earliest slot the sender can be in is=20 >computed based on packet arrival time, t_j (in TESLA-intro section 3.5): > floor[(t_j - T_0)/T_int =3D K_i] > >The slot K_s that the sender appears to have been in when it sent the=20 >packet can be computed based on RTP timestamp, t_s: > floor[(t_s - T_0)/T_int =3D K_s] > >If there's significant delay in the sender stack after the RTP timestamp=20 >is applied, that doesn't change the security; it can just all be put down= =20 >as extra network delay (but avoidable by more careful implementation). > >2/ Just to emphasise a point that Adrian Perrig reminded me of when we met= =20 >(offline) recently.... > >This use of the RTP timestamp (just like use of the key index) must not be= =20 >assumed to say anything authentic about the time the packet was sent until= =20 >after the packet is authenticated. It is merely a hint as to which key to= =20 >try in order to see whether the packet is authentic. Then, only if the key= =20 >the timestamps hints at does indeed create a matching MAC to that in the=20 >packet, can one say that the timestamp (or key index) was indeed=20 >authentic. This is implicit authentication - because correct=20 >authentication depended on it. > >So, we must still have the timeslot plan for the whole key chain signed in= =20 >advance under an asymmetric key. The timestamps or key indices in the=20 >packets are NOT authentic until proven so by implicit authentication. > > >Bob > >___________________________________________________________________________= _ >Bob Briscoe, Networks Research Centre, BT= Research >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473= 645196 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 12:49:56 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24405 for ; Tue, 14 Sep 2004 12:49:55 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AAB5F8CCCB; Tue, 14 Sep 2004 12:49:57 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B40778D275 for ; Tue, 14 Sep 2004 12:49:56 -0400 (EDT) Received: (qmail 93285 invoked by uid 3269); 14 Sep 2004 16:49:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93282 invoked from network); 14 Sep 2004 16:49:56 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 14 Sep 2004 16:49:56 -0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8EGntAh022091 for ; Tue, 14 Sep 2004 18:49:55 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 18:49:55 +0200 Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Sep 2004 18:49:55 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BC5D4@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: "'Bob Briscoe'" Subject: RE: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Tue, 14 Sep 2004 18:44:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Sep 2004 16:49:55.0536 (UTC) FILETIME=[DCDCC500:01C49A7A] Cc: canetti , Mark Baugher , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Bob! AFAIK, that is the way RTP works, unfortunately (I'd be the first happy to save bytes ;o)) Cheers /E > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of Bob Briscoe > Sent: den 14 september 2004 18:37 > To: Elisabetta Carrara (KI/EAB) > Cc: canetti; Mark Baugher; msec@securemulticast.org > Subject: Fwd: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt > (long) > > > Elisabetta, > > Just made the mistake of sending before reading (I just read > your 31 Aug 04 > posting on msec)... > > You make it clear that the RTP timestamp isn't as reliable as > I thought. Is > this possible by design, or just due to some crap implementations? > > So, I guess the advice should be to add a key index field unless the > implementor is sure of the reliability of the RTP timestamp. If this > assurance is going to be rare, it's a good argument for not > allowing any > option, and always mandating the addition of a key index field... > > ...However, I'm wary of forcing 32 redundant bits per packet > just because > another code module is often flakey. THat's more an argument > for fixing the > flakey code, not adding bloat to allow for flakiness > elsewhere. It's not > unreasonable to expect that adding time-dependent security to an RTP > implementation will require tightening up pre-existing > timestamping code. > > Of course, there might be a problem if you don't have access > to someone > else's RTP source that you depend on. But is this really a > likely scenario? > > > Bob > > > >Date: Tue, 14 Sep 2004 17:12:47 +0100 > >To: canetti > >From: Bob Briscoe > >Subject: Re: [MSEC] Review of > draft-ietf-msec-srtp-tesla-01.txt (long) > >Cc: Mark Baugher , msec@securemulticast.org > >Bcc: f\Charging\Security\IN msec > > > >Ran, > > > >At 05:14 31/08/2004, canetti wrote: > >>2. I think that Bob's idea of having the receiver infer the interval > >>number from the RTP timestamp may work in some/many cases. > But it might > >>make the programming more delicate and harder to get right. > One potential > >>solution is just to opt for a more robust design at the > price of extra 4 > >>bytes p.p. altenratively, we can make the interval number > optional and > >>leave it up to the implementation whether it wants to save > the extra 4 > >>bytes or not. > > > >1/ It's really not delicate or hard... > > > >Just like when on reception, the earliest slot the sender > can be in is > >computed based on packet arrival time, t_j (in TESLA-intro > section 3.5): > > floor[(t_j - T_0)/T_int = K_i] > > > >The slot K_s that the sender appears to have been in when it > sent the > >packet can be computed based on RTP timestamp, t_s: > > floor[(t_s - T_0)/T_int = K_s] > > > >If there's significant delay in the sender stack after the > RTP timestamp > >is applied, that doesn't change the security; it can just > all be put down > >as extra network delay (but avoidable by more careful > implementation). > > > >2/ Just to emphasise a point that Adrian Perrig reminded me > of when we met > >(offline) recently.... > > > >This use of the RTP timestamp (just like use of the key > index) must not be > >assumed to say anything authentic about the time the packet > was sent until > >after the packet is authenticated. It is merely a hint as to > which key to > >try in order to see whether the packet is authentic. Then, > only if the key > >the timestamps hints at does indeed create a matching MAC to > that in the > >packet, can one say that the timestamp (or key index) was indeed > >authentic. This is implicit authentication - because correct > >authentication depended on it. > > > >So, we must still have the timeslot plan for the whole key > chain signed in > >advance under an asymmetric key. The timestamps or key > indices in the > >packets are NOT authentic until proven so by implicit authentication. > > > > > >Bob > > > >_____________________________________________________________ > _______________ > >Bob Briscoe, Networks Research > Centre, BT Research > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research > Centre, BT Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 12:57:04 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24997 for ; Tue, 14 Sep 2004 12:57:04 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 548478D31B; Tue, 14 Sep 2004 12:57:06 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5C1468D315 for ; Tue, 14 Sep 2004 12:57:05 -0400 (EDT) Received: (qmail 94331 invoked by uid 3269); 14 Sep 2004 16:57:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94328 invoked from network); 14 Sep 2004 16:57:05 -0000 Received: from saturn.bt.com (HELO cbibipnt05.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 14 Sep 2004 16:57:05 -0000 Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SABLM0DD; Tue, 14 Sep 2004 17:57:18 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1095181038174; Tue, 14 Sep 2004 17:57:18 +0100 Received: from mut.jungle.bt.co.uk (maat.jungle.bt.co.uk [132.146.108.145]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i8EGuxP3025618; Tue, 14 Sep 2004 17:57:01 +0100 Message-Id: <5.2.1.1.2.20040914174749.01aaa9d8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 14 Sep 2004 17:58:19 +0100 To: Mark Baugher From: Bob Briscoe Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: References: <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: elisabetta.carrara@ericsson.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Mark, At 23:49 12/09/2004, Mark Baugher wrote: >hi Bob > Just to recap this thread: We agreed to make the group MAC a >RECOMMENDED feature rather than required. We'll use you editorial >comments as a guide when we make the next update to the specification. >And we'll look forward to reviewing DoS points in a subsequent revision >of the base TESLA I-D. Yup. I've quoted my five original points below with the resolutions so far, as far as I understand them. >1/ Key index field is redundant with SRTP = Debate current on list (Replies to that thread not this, pls) >2/ Non-TESLA group authentication to protect against DoS should be >optional = Agreed should be RECOMMENDED >3/ Non-TESLA group authentication to protect against DoS is redundant = Related to point 2/ and depends on write-up of alternative DoS protection in a new TESLA-intro (I sent a new draft to my co-authors last Fri for sanity checking - should be on the msec list soon). >4/ No need to include the key index, i, in the TESLA authenticated >portion = Agreed >5/ Discard if a packet cannot be authenticated should be optional = Agreed >Nits = To be considered in next draft. Cheers Bob >thanks, Mark >On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote: > >>Mark, >> >>At 18:49 30/08/2004, Mark Baugher wrote: >>>Bob, >>> I reply to many of your points below, but here is something I'd like >>>for you and your co-authors to consider: Apart from reusing the RTP >>>timestamp field the issue you raise in point 3 is a general TESLA >>>issue >>>and not an SRTP-TESLA issue. I think this is also true for guidance >>>on >>>the use or non-use of a group MAC, which is related to your point 3. >>>I'd like to see these points treated in a general way so why not >>>critique the base TESLA spec on this point and not SRTP-TESLA? >> >>Yup, for the DoS prevention, Ran Canetti has proposed we need to add a >>more formal DoS mitigation section to TESLA-intro. >> >>This mail thread just goes to show how getting specific about a >>protocol (SRTP) feeds back to the generic description. It was only >>when we got to the specifics that the issues became clear. I'll stop >>pestering you for a while on point 3/ (DoS prevention). >> >>On use/non-use of group MAC, TESLA-intro won't MANDATE anything. It's >>informational. >> >>More inline. >> >>> More below... >>>On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: >>>... >>>>Having thought about it, I will be stronger than the last mail and >>>>say >>>>a group MAC will provide barely any additional protection in most >>>>circumstances so should not be the default. The logic of using a >>>>group >>>>MAC with TESLA looks like this: >>>> >>>> Sender's level of trust in group members not to spoof packets >>>> | using a group key? | >>>> Low High >>>> | | >>>> Use source authentication (ie TESLA). Use group >>>>authentication. >>>> | >>>> TESLA is vulnerable to DoS filling buffer >>>> until delayed auth >>>> | >>>> Use group authentication alongside TESLA >>>> (as in current SRTP draft) >>>> >>>>I hope this diagram helps highlight the broken logic. >>>>Group authentication is being MANDATED in the SRTP draft in a >>>>scenario >>>>which only ever arises where the group isn't trusted. >>> >>>Trusted to do or not do what? I think in this case, "trusted" means >>>"trusted not to launch a denial of service attack against the group." >>>There is also "trusted not to capture a disclosed key to successfully >>>impersonate a group sender." Further, there is "trusted not to >>>disclose a group key" - and so on. Treating something as complicated >>>as this as "high" or "low" is not persuading me, personally. >> >>I started out the diag making clear the trust context, but yes, it got >>munged into unspecified trust in the explanatory para after. SOrry. I >>think it best if I write all the applicability stuff into a new DoS >>sectino in the TESLA-intro, then we can have this debate with some >>clarity. >> >>I hope to do this while the issue is fresh - next few days, but... >> >> >>>>dding group authentication to TESLA only provides any additional >>>>value >>>>for the narrow range of scenarios where group members aren't trusted >>>>enough to use group authentication alone, but they are trusted >>>>sufficiently that group authentication might detect some DoS attacks >>>>- >>>>pretty slim odds. Worth allowing as an option, but surely not >>>>MANDATING. >>> >>>You see a waste of time and bandwidth for protection that is >>>superfluous. I see a relatively cheap way to keep a group protected >>>against anyone running a kiddie script who decides to send a burst of >>>packets and overflow members' buffers. Let's gather some more opinion >>>from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. >> >>The S/KEY-like scheme in point 3/ is an alternative, but it's now >>different to what I described following Adrian Perrig knocking it >>down,... me fixing it,... then Adrian agreeing it's now OK. It's now a >>good option for fixed or nearly-fixed packet rate (eg audio), but >>needs applicability carefully explaining for highly variable packet >>rate (eg video). >> >>I've agreed to document three DoS mitigation possibilities in a next >>TESLA-intro draft: >>* check that the disclosed key fits the chain (simple but weak - >>always worth doing) >>* group MAC >>* disclose & use new key each packet >> >>I think it's best to wait for that before the debate on what >>defaults/options/transforms there should be in SRTP-TESLA. >> >>I've split the remaining reply into separate threads for each numbered >>issue I raised at least those still up for debate, as requested. THey >>are all orthogonal. >> >> >> >>>>>>2/ Non-TESLA group authentication to protect against DoS should be >>>>>>optional >>>>>>------------------------------------------------------------------- >>>>>>-- -- ---- >>>>>>The immediate authentication provided by your non-TESLA group >>>>>>authentication only protects against DoS by non-group members. It >>>>>>should be RECOMMENDED not REQUIRED (section 7). >>>>> >>>>>I think that this point should be resolved in the base TESLA >>>>>specification, i.e. I don't think there is anything that is >>>>>SRTP-specific to this point. But we did not treat it that way in >>>>>SRTP-TESLA, and that's probably my fault. Nonetheless, I think it >>>>>should be REQUIRED in base TESLA. >>>> >>>>Currently section 5 (security considerations) of the TESLA-intro >>>>mentions group authentication as one possible way of preventing >>>>flooding attacks during the key disclosure delay. But it doesn't >>>>MANDATE it. I'm simply taking issue with group authentication being >>>>MANDATED in SRTP-TESLA, as I don't think it's effective in many >>>>(most?) scenarios, making it unnecessary overhead. >>>> >>>>I have no problem with making a group MAC optional for scenarios >>>>where >>>>it does improve matters. >>> >>>I don't have a lot of religious fervor on the topic either though I >>>like to avoid options in security protocols whenever possible. What >>>seemed fairly obvious to me obviously seems wasteful to you. I'd like >>>to discuss this further in a separate thread. We are really >>>discussing >>>a security requirement for protecting groups. >>>... >>> >>>> >>>>Sorry, history was a distracting word. I meant likelihood. Imagine a >>>>video conf between senior execs of competing companies, or between >>>>representatives of mutually distrusting governments. They don't trust >>>>each other not to spoof what the other parties are saying, but they >>>>have no likelihood of one launching a flooding attack on the other >>>>(e.g. the whole thing is over a joint VPN). They need group >>>>authentication like a phish needs a bicycle. So why MANDATE it? >>> >>>We are beating this to death and confusing one another. The >>>participants would not launch the flooding attack; an interloper would >>>do it. If it's over a VPN, then the attack seems very unlikely - as >>>is >>>source spoofing in a small teleconference, for that matter. >>>... >>>> >>>>>relies upon the fact that memory gets tied up while >>>>>packets are buffered awaiting authentication. In this case, there >>>>>is >>>>>no buffering of multiple packets, just one packet during the >>>>>disclosure >>>>>interval. Do I understand you correctly? >>>> >>>>No. The disclosure *interval* (delay) still spans multiple packets. >>>>The new feature depends on each key now only ever being *disclosed* >>>>once, rather than the same key being disclosed repeatedly as it was >>>>when there were multiple packets in the same TESLA time interval. >>> >>>Before we go any further into this, I'd like to understand why this >>>disclosure scheme needs to be considered only for SRTP. You mention >>>below that you also think that it belongs in the base TESLA >>>specification and that you have raised the issue with your co-authors? >>>I think the TESLA co-authors might want to consider discussing this on >>>the list. That sounds better than treating SRTP-TESLA as the poster >>>child for something that was maybe overlooked in the base TESLA >>>document. >>> >>>I just got back from some personal time off and am working through >>>several hundred messages - I prioritized yours. It would be a more >>>efficient discussion to discuss this with the TESLA authors - on the >>>msec list if possible. >>> >>>> >>>>As soon as a packet arrives, the disclosed key in it now has two >>>>purposes: >>>>- it's original TESLA purpose: to verify a packet received some time >>>>previously >>>>- to immediately show the receiver that the sender of this packet >>>>knew >>>>the next key back along the hash chain which is now only ever >>>>*disclosed* once >>>> >>>>So if more packets are received that *disclose* the same key, the >>>>receiver can assume (at least until the delayed TESLA verification) >>>>that only the first packet to disclose each key was genuine. >>>> >>>>If a network element is compromised, an attacker can discover the >>>>next >>>>disclosed key and overtake or replace a genuine packet with many >>>>others. But the receiver can still immediately discard all but the >>>>first to arrive, protecting itself from memory overflow. >>>> >>>>So the scheme has the following properties: >>>>- The receiver will never buffer more than one packet per packet sent >>>>by the genuine sender (so the receiver's buffer fill rate is still >>>>clocked by the party that reveals each new key backwards in the >>>>chain). >>>>- As each key is later disclosed, TESLA can do delayed verification >>>>of >>>>these stored packets. >>>> - if they pass delayed verfication, the messages must be genuine >>>> - if they fail delayed verfication, the messages must not have been >>>>genuine >>>>- The true message will have been lost in the latter case. But, then >>>>if an attacker can compromise a network element, it can discard the >>>>true messages anyway (a group MAC can't prevent this either ;) >>>> >>>>I need to fully document this. There are some corner cases not >>>>covered >>>>by the above. I've given an outline later. Obviously, this DoS >>>>protection idea hasn't had the same peer-review as TESLA, except it >>>>is >>>>essentially just S/KEY, which has had ample peer review (but perhaps >>>>not in a group setting). >>> >>>This sounds promising to me, but I would like to see the document - I >>>have not read the one you sent me yet. And I would like to hear what >>>the other TESLA authors have to say about it. >>> >>>... >>>>>If so, why >>>>>not put this in the core TESLA specification. I'd say that if it >>>>>belongs in SRTP-TESLA, then it belongs in the core specification. >>>>>No? >>>> >>>>You are absolutely correct. >>>> >>>>We (the co-authors of the TESLA base spec) are discussing this >>>>off-line right now. It's my fault we didn't reach closure on it >>>>before >>>>TESLA got this far. I was originally pushing this as an option, but I >>>>think I never quite got myself understood. Somewhere in the mists of >>>>time I gave up. I've been taking a back seat on the TESLA work until >>>>just recently, so my brain obviously wasn't in gear when reviewing >>>>drafts. I forgot I'd got this option to attack the DoS problem. It >>>>was >>>>only through reveiwing the SRTP draft that the technique came back to >>>>me. Now, the more I argue about it, the better I think it is. >>>> >>>>However, it's not out of the woods yet. My co-authors are trying to >>>>break it. I believe I've defended it in the case of variable packet >>>>rate and packet misordering. But I'm expecting more attempts to break >>>>it (and, of course, anyone on this list is welcome to try as well). >>>> >>>>If it comes out intact, you should see text on it shortly. Otherwise, >>>>I guess the TESLA base spec will stay as it is. >>> >>>And this sizable email exchange would be in vain :?) >>> >>>... >>>>>>BTW, it should be pointed out that the verification algo should >>>>>>check >>>>>>the key index is within an expected range before using it (e.g. >>>>>>only >>>>>>a >>>>>>small increment above the last highest verified key index seen). >>>>>>Otherwise, an attacker can tamper with this field to lead all >>>>>>receivers to run millions of hash operations unnecessarily. I >>>>>>prefer >>>>>>to call it a key-index *hint*, to remind me not to rely on it being >>>>>>correct. >>>>> >>>>>This sounds like an argument for keeping the MAC. >>>> >>>>No. It is an argument for watching that it doesn't appear to imply >>>>packets are extremely re-ordered (e.g. it must be no more than, say, >>>>64 different from the previous highest index, cf the SRTP replay >>>>protection window). You /could/ use a group MAC to do an initial test >>>>of its integrity, but why waste 10 octets when you can do a test that >>>>uses none? And this would only work if you trusted the group members >>>>(recall, we are using TESLA because we don't trust them). >>> >>>The group MAC was originally 4 bytes and I need to check with >>>Elisabetta to find out why it is now 10. I don't see why it needs to >>>be larger than 4 bytes for group MAC purposes. If we manage to >>>obviate >>>the need for group MACs in TESLA, then it can be zero bytes and I'll >>>be >>>perfectly happy. >>>> >>>>The key index is implicitly authenticated (similar to the implicit >>>>header authentication in section 9.5.2 of the SRTP RFC) because the >>>>TESLA MAC depends on it. If the key index is tampered with, the >>>>authentication test will fail as it should. >>> >>>Ok. >>>... >>>>> >>>>>We'll refer to your editorial comments at the next revision. >>>> >>>>I've added a couple more below... >>> >>>Good. How do you feel about my proposal to consider the proposed use >>>of the RTP timestamp field separately from the group MAC. And treat >>>the group MAC as a related question to your point 3 scheme? >> >>Yup. Done. >> >>Cheers >> >> >>Bob >> >> >>_______________________________________________________________________ _____ >>Bob Briscoe, Networks Research Centre, BT >>Research >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 >>645196 >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://six.pairlist.net/mailman/listinfo/msec > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 13:05:12 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25483 for ; Tue, 14 Sep 2004 13:05:11 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 705438D431; Tue, 14 Sep 2004 13:05:13 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id EEA098CC8D for ; Tue, 14 Sep 2004 13:05:10 -0400 (EDT) Received: (qmail 95970 invoked by uid 3269); 14 Sep 2004 17:05:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95967 invoked from network); 14 Sep 2004 17:05:10 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 14 Sep 2004 17:05:10 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2004 10:07:24 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn4-290.cisco.com [10.21.81.34]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8EH4fLp024707; Tue, 14 Sep 2004 10:04:42 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <2541002C-0670-11D9-BEEA-000A95DC10F2@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Tue, 14 Sep 2004 10:04:31 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: "Elisabetta Carrara (KI/EAB)" , canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable hi Bob On Sep 14, 2004, at 9:37 AM, Bob Briscoe wrote: > Elisabetta, > > Just made the mistake of sending before reading (I just read your 31 =20= > Aug 04 posting on msec)... > > You make it clear that the RTP timestamp isn't as reliable as I =20 > thought. Is this possible by design, or just due to some crap =20 > implementations? It's by design, I believe: If the timestamp is the presentation =20 timestamp as in some MPEG types and a group of packets make up one =20 presentation unit, then they will all have the same timestamp. Mark > > So, I guess the advice should be to add a key index field unless the =20= > implementor is sure of the reliability of the RTP timestamp. If this =20= > assurance is going to be rare, it's a good argument for not allowing =20= > any option, and always mandating the addition of a key index field... > > ...However, I'm wary of forcing 32 redundant bits per packet just =20 > because another code module is often flakey. THat's more an argument =20= > for fixing the flakey code, not adding bloat to allow for flakiness =20= > elsewhere. It's not unreasonable to expect that adding time-dependent =20= > security to an RTP implementation will require tightening up =20 > pre-existing timestamping code. > > Of course, there might be a problem if you don't have access to =20 > someone else's RTP source that you depend on. But is this really a =20 > likely scenario? > > > Bob > > >> Date: Tue, 14 Sep 2004 17:12:47 +0100 >> To: canetti >> From: Bob Briscoe >> Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt = (long) >> Cc: Mark Baugher , msec@securemulticast.org >> Bcc: =83\Charging\Security\IN msec >> >> Ran, >> >> At 05:14 31/08/2004, canetti wrote: >>> 2. I think that Bob's idea of having the receiver infer the interval >>> number from the RTP timestamp may work in some/many cases. But it =20= >>> might >>> make the programming more delicate and harder to get right. One =20 >>> potential >>> solution is just to opt for a more robust design at the price of =20 >>> extra 4 >>> bytes p.p. altenratively, we can make the interval number optional =20= >>> and >>> leave it up to the implementation whether it wants to save the extra = =20 >>> 4 >>> bytes or not. >> >> 1/ It's really not delicate or hard... >> >> Just like when on reception, the earliest slot the sender can be in =20= >> is computed based on packet arrival time, t_j (in TESLA-intro section = =20 >> 3.5): >> floor[(t_j - T_0)/T_int =3D K_i] >> >> The slot K_s that the sender appears to have been in when it sent the = =20 >> packet can be computed based on RTP timestamp, t_s: >> floor[(t_s - T_0)/T_int =3D K_s] >> >> If there's significant delay in the sender stack after the RTP =20 >> timestamp is applied, that doesn't change the security; it can just =20= >> all be put down as extra network delay (but avoidable by more careful = =20 >> implementation). >> >> 2/ Just to emphasise a point that Adrian Perrig reminded me of when =20= >> we met (offline) recently.... >> >> This use of the RTP timestamp (just like use of the key index) must =20= >> not be assumed to say anything authentic about the time the packet =20= >> was sent until after the packet is authenticated. It is merely a hint = =20 >> as to which key to try in order to see whether the packet is =20 >> authentic. Then, only if the key the timestamps hints at does indeed =20= >> create a matching MAC to that in the packet, can one say that the =20 >> timestamp (or key index) was indeed authentic. This is implicit =20 >> authentication - because correct authentication depended on it. >> >> So, we must still have the timeslot plan for the whole key chain =20 >> signed in advance under an asymmetric key. The timestamps or key =20 >> indices in the packets are NOT authentic until proven so by implicit =20= >> authentication. >> >> >> Bob >> >> = ______________________________________________________________________=20= >> ______ >> Bob Briscoe, Networks Research Centre, BT =20= >> Research >> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 = =20 >> 645196 > > = _______________________________________________________________________=20= > _____ > Bob Briscoe, Networks Research Centre, BT =20= > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 =20= > 645196 > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 13:06:18 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25565 for ; Tue, 14 Sep 2004 13:06:18 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5A85A8D66C; Tue, 14 Sep 2004 13:06:20 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 31FEB8D5A2 for ; Tue, 14 Sep 2004 13:06:19 -0400 (EDT) Received: (qmail 96168 invoked by uid 3269); 14 Sep 2004 17:06:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96165 invoked from network); 14 Sep 2004 17:06:19 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 14 Sep 2004 17:06:19 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2004 10:08:33 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8EH5vpH024662; Tue, 14 Sep 2004 10:06:12 -0700 (PDT) Received: from [128.107.163.74] (dhcp-128-107-163-74.cisco.com [128.107.163.74]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXC35382; Tue, 14 Sep 2004 10:04:50 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <5A6EFCF6-0670-11D9-9DBB-0003935495EC@cisco.com> Content-Transfer-Encoding: quoted-printable From: "David A. McGrew" Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Tue, 14 Sep 2004 10:06:00 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: "'msec@securemulticast.org'" X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Bob, On Sep 14, 2004, at 9:37 AM, Bob Briscoe wrote: > Elisabetta, > > Just made the mistake of sending before reading (I just read your 31 =20= > Aug 04 posting on msec)... > > You make it clear that the RTP timestamp isn't as reliable as I =20 > thought. Is this possible by design, or just due to some crap =20 > implementations? The non-regularity of the RTP timestamp is not just due to bad =20 implementations. =46rom the RTP FAQ maintained by Henning Schulzrinne =20 (http://www.cs.columbia.edu/~hgs/rtp/faq.html#timestamp-seqno): What are the roles of the RTP timestamp and sequence numbers? The timestamp is used to place the incoming audio and video packets in =20= the correct timing order (playout delay compensation). The sequence =20 number is mainly used to detect losses. Sequence numbers increase by =20 one for each RTP packet transmitted, timestamps increase by the time =20 "covered" by a packet. For video formats where a video frame is split =20= across several RTP packets, several packets may have the same =20 timestamp. In some cases such as carrying DTMF (touch tone) data (RFC =20= 2833), RTP timestamps may not be monotonic. We also have to consider that there may be codec changes during a =20 single TESLA flow, in which case the timestamp might change from one =20 monotonic sequence to another, thus disrupting TESLA if it relied on =20 the RTP codec. In my experience with SRTP, it is best to make as few assumptions about =20= the RTP fields as possible. It would be better for SRTP TESLA to not =20= re-use the RTP timestamp, in my opinion, because that will better =20 enable the protocol to be used with existing RTP systems without any =20 security concern. I regret the loss of four bytes packet for a =20 TESLA-specific timestamp, but I would prefer to have a protocol that we =20= could recommend without qualifications. David > > So, I guess the advice should be to add a key index field unless the =20= > implementor is sure of the reliability of the RTP timestamp. If this =20= > assurance is going to be rare, it's a good argument for not allowing =20= > any option, and always mandating the addition of a key index field... > > ...However, I'm wary of forcing 32 redundant bits per packet just =20 > because another code module is often flakey. THat's more an argument =20= > for fixing the flakey code, not adding bloat to allow for flakiness =20= > elsewhere. It's not unreasonable to expect that adding time-dependent =20= > security to an RTP implementation will require tightening up =20 > pre-existing timestamping code. > > Of course, there might be a problem if you don't have access to =20 > someone else's RTP source that you depend on. But is this really a =20 > likely scenario? > > > Bob > > >> Date: Tue, 14 Sep 2004 17:12:47 +0100 >> To: canetti >> From: Bob Briscoe >> Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt = (long) >> Cc: Mark Baugher , msec@securemulticast.org >> Bcc: =83\Charging\Security\IN msec >> >> Ran, >> >> At 05:14 31/08/2004, canetti wrote: >>> 2. I think that Bob's idea of having the receiver infer the interval >>> number from the RTP timestamp may work in some/many cases. But it =20= >>> might >>> make the programming more delicate and harder to get right. One =20 >>> potential >>> solution is just to opt for a more robust design at the price of =20 >>> extra 4 >>> bytes p.p. altenratively, we can make the interval number optional =20= >>> and >>> leave it up to the implementation whether it wants to save the extra = =20 >>> 4 >>> bytes or not. >> >> 1/ It's really not delicate or hard... >> >> Just like when on reception, the earliest slot the sender can be in =20= >> is computed based on packet arrival time, t_j (in TESLA-intro section = =20 >> 3.5): >> floor[(t_j - T_0)/T_int =3D K_i] >> >> The slot K_s that the sender appears to have been in when it sent the = =20 >> packet can be computed based on RTP timestamp, t_s: >> floor[(t_s - T_0)/T_int =3D K_s] >> >> If there's significant delay in the sender stack after the RTP =20 >> timestamp is applied, that doesn't change the security; it can just =20= >> all be put down as extra network delay (but avoidable by more careful = =20 >> implementation). >> >> 2/ Just to emphasise a point that Adrian Perrig reminded me of when =20= >> we met (offline) recently.... >> >> This use of the RTP timestamp (just like use of the key index) must =20= >> not be assumed to say anything authentic about the time the packet =20= >> was sent until after the packet is authenticated. It is merely a hint = =20 >> as to which key to try in order to see whether the packet is =20 >> authentic. Then, only if the key the timestamps hints at does indeed =20= >> create a matching MAC to that in the packet, can one say that the =20 >> timestamp (or key index) was indeed authentic. This is implicit =20 >> authentication - because correct authentication depended on it. >> >> So, we must still have the timeslot plan for the whole key chain =20 >> signed in advance under an asymmetric key. The timestamps or key =20 >> indices in the packets are NOT authentic until proven so by implicit =20= >> authentication. >> >> >> Bob >> >> = ______________________________________________________________________=20= >> ______ >> Bob Briscoe, Networks Research Centre, BT =20= >> Research >> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 = =20 >> 645196 > > = _______________________________________________________________________=20= > _____ > Bob Briscoe, Networks Research Centre, BT =20= > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 =20= > 645196 > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 14:25:10 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02101 for ; Tue, 14 Sep 2004 14:25:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E543F8C220; Tue, 14 Sep 2004 14:25:05 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 908348C1F0 for ; Tue, 14 Sep 2004 14:25:04 -0400 (EDT) Received: (qmail 11838 invoked by uid 3269); 14 Sep 2004 18:25:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11835 invoked from network); 14 Sep 2004 18:25:04 -0000 Received: from saturn.bt.com (HELO cbibipnt08.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 14 Sep 2004 18:25:04 -0000 Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RRCZLXAZ; Tue, 14 Sep 2004 19:25:13 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1095186312703; Tue, 14 Sep 2004 19:25:12 +0100 Received: from mut.jungle.bt.co.uk (maat.jungle.bt.co.uk [132.146.108.145]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i8EIOwP3026543; Tue, 14 Sep 2004 19:25:01 +0100 Message-Id: <5.2.1.1.2.20040914183456.01b2d310@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 14 Sep 2004 19:24:54 +0100 To: "David A. McGrew" , Mark Baugher , "Elisabetta Carrara (KI/EAB)" From: Bob Briscoe Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: <5A6EFCF6-0670-11D9-9DBB-0003935495EC@cisco.com> References: <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'msec@securemulticast.org'" X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org David, Mark, At 18:06 14/09/2004, David A. McGrew wrote: >In my experience with SRTP, it is best to make as few assumptions about >the RTP fields as possible. It would be better for SRTP TESLA to not >re-use the RTP timestamp, in my opinion, because that will better >enable the protocol to be used with existing RTP systems without any >security concern. I regret the loss of four bytes packet for a >TESLA-specific timestamp, but I would prefer to have a protocol that we >could recommend without qualifications. Tx for both your explanations, which make it all much clearer why it's more complicated. I've scanned the refs you gave and now I know how much I don't know. Although you all seem to know a fair bit about this and have a good deal of experience, may I be so bold as to say that I detect there is an element of assuming there might be a problem, rather than strictly analysing whether there really is a problem. This is relevant to whether we make a key index field MANDATORY or OPTIONAL. I'm just wary of adding bloat to a protocol because no-one can work out (without a lot of work) whether it is needed or not. If the key index were derived from the RTP timestamp: i) TESLA security would depend absolutely on the RTP timestamp not stating a time AFTER the packet had been sent. I can't see a case where this might happen. Is there? ii) Also TESLA performance would depend on the RTP timestamp not stating a time too far (x) prior to sending (eg when a video frame is split into multiple packets). If (network_delay + x) still allowed a workable authentication delay, there might not be a performance problem. It seems that the various timestamp bases can all be recalculated back to wallclock time. So changing codecs, etc should all be OK. But, I have a great deal of uncertainty over that statement. At first sight, PSTN gateways seem a problem: converting DTMF tones in the audio to a new stream of telephony event media packets. Clearly, these would be timestamped after they left the original sender. But, of course, being new payloads, these would have to be authenticated by the gateway, not the sender. Requiring each TESLA receiver to time synch with the gateway as another source. Arrrgghh - the complications of legacy... ...but importantly these are complications, not protocol failures. Do you get my drift? THe real question is: - MANDATORY key index because we're sure dependence on the RTP timestamp will cause security or performance failures in ALL cases (or such a large majory of cases that having an option would cause unnecessary complication) - OPTIONAL key index, because we think it might cause problems, but no-one can be bothered to work it all out to see whether there will be a significant number of cases that CAN safely rely on the RTP timestamp. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 14:58:12 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04264 for ; Tue, 14 Sep 2004 14:58:12 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8D8CB8C594; Tue, 14 Sep 2004 14:56:50 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 118038C58D for ; Tue, 14 Sep 2004 14:56:49 -0400 (EDT) Received: (qmail 18170 invoked by uid 3269); 14 Sep 2004 18:56:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18167 invoked from network); 14 Sep 2004 18:56:48 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 14 Sep 2004 18:56:48 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2004 11:59:03 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn4-290.cisco.com [10.21.81.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8EIuWxl019478; Tue, 14 Sep 2004 11:56:35 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20040914174749.01aaa9d8@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040914174749.01aaa9d8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Tue, 14 Sep 2004 11:55:22 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: elisabetta.carrara@ericsson.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit hi Bob On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote: > ... > > >> 5/ Discard if a packet cannot be authenticated should be optional > = Agreed I did not sign up for this one - or at least I did not mean to. I'd like to discuss this some more. Personally, I want to limit options wherever possible and this is the second option (including making the group optional) that you have proposed. I don't think we necessarily want to add this particular option and would like to hear what others have to say on the matter. thanks, Mark > >> Nits > = To be considered in next draft. > > Cheers > > > Bob > >> thanks, Mark >> On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote: >> >>> Mark, >>> >>> At 18:49 30/08/2004, Mark Baugher wrote: >>>> Bob, >>>> I reply to many of your points below, but here is something I'd >>>> like >>>> for you and your co-authors to consider: Apart from reusing the RTP >>>> timestamp field the issue you raise in point 3 is a general TESLA >>>> issue >>>> and not an SRTP-TESLA issue. I think this is also true for guidance >>>> on >>>> the use or non-use of a group MAC, which is related to your point 3. >>>> I'd like to see these points treated in a general way so why not >>>> critique the base TESLA spec on this point and not SRTP-TESLA? >>> >>> Yup, for the DoS prevention, Ran Canetti has proposed we need to add >>> a >>> more formal DoS mitigation section to TESLA-intro. >>> >>> This mail thread just goes to show how getting specific about a >>> protocol (SRTP) feeds back to the generic description. It was only >>> when we got to the specifics that the issues became clear. I'll stop >>> pestering you for a while on point 3/ (DoS prevention). >>> >>> On use/non-use of group MAC, TESLA-intro won't MANDATE anything. It's >>> informational. >>> >>> More inline. >>> >>>> More below... >>>> On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: >>>> ... >>>>> Having thought about it, I will be stronger than the last mail and >>>>> say >>>>> a group MAC will provide barely any additional protection in most >>>>> circumstances so should not be the default. The logic of using a >>>>> group >>>>> MAC with TESLA looks like this: >>>>> >>>>> Sender's level of trust in group members not to spoof packets >>>>> | using a group key? | >>>>> Low High >>>>> | | >>>>> Use source authentication (ie TESLA). Use group >>>>> authentication. >>>>> | >>>>> TESLA is vulnerable to DoS filling buffer >>>>> until delayed auth >>>>> | >>>>> Use group authentication alongside TESLA >>>>> (as in current SRTP draft) >>>>> >>>>> I hope this diagram helps highlight the broken logic. >>>>> Group authentication is being MANDATED in the SRTP draft in a >>>>> scenario >>>>> which only ever arises where the group isn't trusted. >>>> >>>> Trusted to do or not do what? I think in this case, "trusted" means >>>> "trusted not to launch a denial of service attack against the >>>> group." >>>> There is also "trusted not to capture a disclosed key to >>>> successfully >>>> impersonate a group sender." Further, there is "trusted not to >>>> disclose a group key" - and so on. Treating something as >>>> complicated >>>> as this as "high" or "low" is not persuading me, personally. >>> >>> I started out the diag making clear the trust context, but yes, it >>> got >>> munged into unspecified trust in the explanatory para after. SOrry. I >>> think it best if I write all the applicability stuff into a new DoS >>> sectino in the TESLA-intro, then we can have this debate with some >>> clarity. >>> >>> I hope to do this while the issue is fresh - next few days, but... >>> >>> >>>>> dding group authentication to TESLA only provides any additional >>>>> value >>>>> for the narrow range of scenarios where group members aren't >>>>> trusted >>>>> enough to use group authentication alone, but they are trusted >>>>> sufficiently that group authentication might detect some DoS >>>>> attacks >>>>> - >>>>> pretty slim odds. Worth allowing as an option, but surely not >>>>> MANDATING. >>>> >>>> You see a waste of time and bandwidth for protection that is >>>> superfluous. I see a relatively cheap way to keep a group protected >>>> against anyone running a kiddie script who decides to send a burst >>>> of >>>> packets and overflow members' buffers. Let's gather some more >>>> opinion >>>> from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, >>>> BELOW. >>> >>> The S/KEY-like scheme in point 3/ is an alternative, but it's now >>> different to what I described following Adrian Perrig knocking it >>> down,... me fixing it,... then Adrian agreeing it's now OK. It's now >>> a >>> good option for fixed or nearly-fixed packet rate (eg audio), but >>> needs applicability carefully explaining for highly variable packet >>> rate (eg video). >>> >>> I've agreed to document three DoS mitigation possibilities in a next >>> TESLA-intro draft: >>> * check that the disclosed key fits the chain (simple but weak - >>> always worth doing) >>> * group MAC >>> * disclose & use new key each packet >>> >>> I think it's best to wait for that before the debate on what >>> defaults/options/transforms there should be in SRTP-TESLA. >>> >>> I've split the remaining reply into separate threads for each >>> numbered >>> issue I raised at least those still up for debate, as requested. THey >>> are all orthogonal. >>> >>> >>> >>>>>>> 2/ Non-TESLA group authentication to protect against DoS should >>>>>>> be >>>>>>> optional >>>>>>> ----------------------------------------------------------------- >>>>>>> -- -- -- ---- >>>>>>> The immediate authentication provided by your non-TESLA group >>>>>>> authentication only protects against DoS by non-group members. It >>>>>>> should be RECOMMENDED not REQUIRED (section 7). >>>>>> >>>>>> I think that this point should be resolved in the base TESLA >>>>>> specification, i.e. I don't think there is anything that is >>>>>> SRTP-specific to this point. But we did not treat it that way in >>>>>> SRTP-TESLA, and that's probably my fault. Nonetheless, I think it >>>>>> should be REQUIRED in base TESLA. >>>>> >>>>> Currently section 5 (security considerations) of the TESLA-intro >>>>> mentions group authentication as one possible way of preventing >>>>> flooding attacks during the key disclosure delay. But it doesn't >>>>> MANDATE it. I'm simply taking issue with group authentication being >>>>> MANDATED in SRTP-TESLA, as I don't think it's effective in many >>>>> (most?) scenarios, making it unnecessary overhead. >>>>> >>>>> I have no problem with making a group MAC optional for scenarios >>>>> where >>>>> it does improve matters. >>>> >>>> I don't have a lot of religious fervor on the topic either though I >>>> like to avoid options in security protocols whenever possible. What >>>> seemed fairly obvious to me obviously seems wasteful to you. I'd >>>> like >>>> to discuss this further in a separate thread. We are really >>>> discussing >>>> a security requirement for protecting groups. >>>> ... >>>> >>>>> >>>>> Sorry, history was a distracting word. I meant likelihood. Imagine >>>>> a >>>>> video conf between senior execs of competing companies, or between >>>>> representatives of mutually distrusting governments. They don't >>>>> trust >>>>> each other not to spoof what the other parties are saying, but they >>>>> have no likelihood of one launching a flooding attack on the other >>>>> (e.g. the whole thing is over a joint VPN). They need group >>>>> authentication like a phish needs a bicycle. So why MANDATE it? >>>> >>>> We are beating this to death and confusing one another. The >>>> participants would not launch the flooding attack; an interloper >>>> would >>>> do it. If it's over a VPN, then the attack seems very unlikely - as >>>> is >>>> source spoofing in a small teleconference, for that matter. >>>> ... >>>>> >>>>>> relies upon the fact that memory gets tied up while >>>>>> packets are buffered awaiting authentication. In this case, there >>>>>> is >>>>>> no buffering of multiple packets, just one packet during the >>>>>> disclosure >>>>>> interval. Do I understand you correctly? >>>>> >>>>> No. The disclosure *interval* (delay) still spans multiple packets. >>>>> The new feature depends on each key now only ever being *disclosed* >>>>> once, rather than the same key being disclosed repeatedly as it was >>>>> when there were multiple packets in the same TESLA time interval. >>>> >>>> Before we go any further into this, I'd like to understand why this >>>> disclosure scheme needs to be considered only for SRTP. You mention >>>> below that you also think that it belongs in the base TESLA >>>> specification and that you have raised the issue with your >>>> co-authors? >>>> I think the TESLA co-authors might want to consider discussing this >>>> on >>>> the list. That sounds better than treating SRTP-TESLA as the poster >>>> child for something that was maybe overlooked in the base TESLA >>>> document. >>>> >>>> I just got back from some personal time off and am working through >>>> several hundred messages - I prioritized yours. It would be a more >>>> efficient discussion to discuss this with the TESLA authors - on the >>>> msec list if possible. >>>> >>>>> >>>>> As soon as a packet arrives, the disclosed key in it now has two >>>>> purposes: >>>>> - it's original TESLA purpose: to verify a packet received some >>>>> time >>>>> previously >>>>> - to immediately show the receiver that the sender of this packet >>>>> knew >>>>> the next key back along the hash chain which is now only ever >>>>> *disclosed* once >>>>> >>>>> So if more packets are received that *disclose* the same key, the >>>>> receiver can assume (at least until the delayed TESLA verification) >>>>> that only the first packet to disclose each key was genuine. >>>>> >>>>> If a network element is compromised, an attacker can discover the >>>>> next >>>>> disclosed key and overtake or replace a genuine packet with many >>>>> others. But the receiver can still immediately discard all but the >>>>> first to arrive, protecting itself from memory overflow. >>>>> >>>>> So the scheme has the following properties: >>>>> - The receiver will never buffer more than one packet per packet >>>>> sent >>>>> by the genuine sender (so the receiver's buffer fill rate is still >>>>> clocked by the party that reveals each new key backwards in the >>>>> chain). >>>>> - As each key is later disclosed, TESLA can do delayed verification >>>>> of >>>>> these stored packets. >>>>> - if they pass delayed verfication, the messages must be genuine >>>>> - if they fail delayed verfication, the messages must not have >>>>> been >>>>> genuine >>>>> - The true message will have been lost in the latter case. But, >>>>> then >>>>> if an attacker can compromise a network element, it can discard the >>>>> true messages anyway (a group MAC can't prevent this either ;) >>>>> >>>>> I need to fully document this. There are some corner cases not >>>>> covered >>>>> by the above. I've given an outline later. Obviously, this DoS >>>>> protection idea hasn't had the same peer-review as TESLA, except it >>>>> is >>>>> essentially just S/KEY, which has had ample peer review (but >>>>> perhaps >>>>> not in a group setting). >>>> >>>> This sounds promising to me, but I would like to see the document - >>>> I >>>> have not read the one you sent me yet. And I would like to hear >>>> what >>>> the other TESLA authors have to say about it. >>>> >>>> ... >>>>>> If so, why >>>>>> not put this in the core TESLA specification. I'd say that if it >>>>>> belongs in SRTP-TESLA, then it belongs in the core specification. >>>>>> No? >>>>> >>>>> You are absolutely correct. >>>>> >>>>> We (the co-authors of the TESLA base spec) are discussing this >>>>> off-line right now. It's my fault we didn't reach closure on it >>>>> before >>>>> TESLA got this far. I was originally pushing this as an option, >>>>> but I >>>>> think I never quite got myself understood. Somewhere in the mists >>>>> of >>>>> time I gave up. I've been taking a back seat on the TESLA work >>>>> until >>>>> just recently, so my brain obviously wasn't in gear when reviewing >>>>> drafts. I forgot I'd got this option to attack the DoS problem. It >>>>> was >>>>> only through reveiwing the SRTP draft that the technique came back >>>>> to >>>>> me. Now, the more I argue about it, the better I think it is. >>>>> >>>>> However, it's not out of the woods yet. My co-authors are trying to >>>>> break it. I believe I've defended it in the case of variable packet >>>>> rate and packet misordering. But I'm expecting more attempts to >>>>> break >>>>> it (and, of course, anyone on this list is welcome to try as well). >>>>> >>>>> If it comes out intact, you should see text on it shortly. >>>>> Otherwise, >>>>> I guess the TESLA base spec will stay as it is. >>>> >>>> And this sizable email exchange would be in vain :?) >>>> >>>> ... >>>>>>> BTW, it should be pointed out that the verification algo should >>>>>>> check >>>>>>> the key index is within an expected range before using it (e.g. >>>>>>> only >>>>>>> a >>>>>>> small increment above the last highest verified key index seen). >>>>>>> Otherwise, an attacker can tamper with this field to lead all >>>>>>> receivers to run millions of hash operations unnecessarily. I >>>>>>> prefer >>>>>>> to call it a key-index *hint*, to remind me not to rely on it >>>>>>> being >>>>>>> correct. >>>>>> >>>>>> This sounds like an argument for keeping the MAC. >>>>> >>>>> No. It is an argument for watching that it doesn't appear to imply >>>>> packets are extremely re-ordered (e.g. it must be no more than, >>>>> say, >>>>> 64 different from the previous highest index, cf the SRTP replay >>>>> protection window). You /could/ use a group MAC to do an initial >>>>> test >>>>> of its integrity, but why waste 10 octets when you can do a test >>>>> that >>>>> uses none? And this would only work if you trusted the group >>>>> members >>>>> (recall, we are using TESLA because we don't trust them). >>>> >>>> The group MAC was originally 4 bytes and I need to check with >>>> Elisabetta to find out why it is now 10. I don't see why it needs >>>> to >>>> be larger than 4 bytes for group MAC purposes. If we manage to >>>> obviate >>>> the need for group MACs in TESLA, then it can be zero bytes and I'll >>>> be >>>> perfectly happy. >>>>> >>>>> The key index is implicitly authenticated (similar to the implicit >>>>> header authentication in section 9.5.2 of the SRTP RFC) because the >>>>> TESLA MAC depends on it. If the key index is tampered with, the >>>>> authentication test will fail as it should. >>>> >>>> Ok. >>>> ... >>>>>> >>>>>> We'll refer to your editorial comments at the next revision. >>>>> >>>>> I've added a couple more below... >>>> >>>> Good. How do you feel about my proposal to consider the proposed >>>> use >>>> of the RTP timestamp field separately from the group MAC. And treat >>>> the group MAC as a related question to your point 3 scheme? >>> >>> Yup. Done. >>> >>> Cheers >>> >>> >>> Bob >>> >>> >>> _____________________________________________________________________ >>> __ _____ >>> Bob Briscoe, Networks Research Centre, BT >>> Research >>> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 >>> 645196 >>> >>> _______________________________________________ >>> msec mailing list >>> msec@securemulticast.org >>> http://six.pairlist.net/mailman/listinfo/msec >> >> ______________________________________________________________________ >> ______ >> Bob Briscoe, Networks Research Centre, BT >> Research >> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 >> 645196 > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 15:10:04 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05549 for ; Tue, 14 Sep 2004 15:10:03 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 179BA8CDBB; Tue, 14 Sep 2004 15:10:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 266728CDA6 for ; Tue, 14 Sep 2004 15:10:03 -0400 (EDT) Received: (qmail 20709 invoked by uid 3269); 14 Sep 2004 19:10:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20704 invoked from network); 14 Sep 2004 19:10:03 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by klesh.pair.com with SMTP; 14 Sep 2004 19:10:03 -0000 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8EJ7ZK10872; Tue, 14 Sep 2004 15:07:35 -0400 (EDT) Received: from [47.16.67.20] (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SY400GDR; Tue, 14 Sep 2004 15:07:34 -0400 Message-ID: <41474176.2080401@nortelnetworks.com> Date: Tue, 14 Sep 2004 15:07:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) References: <5.2.1.1.2.20040914174749.01aaa9d8@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20040914174749.01aaa9d8@pop3.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: elisabetta.carrara@ericsson.com, Mark Baugher , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Bob, I am not sure there was consensus on issue #5 below. I don't think it is a good idea to allow a packet to be considered authenticated, when a receiver is not sure about it. Historically speaking, there were a lot of doubts on TESLA with the time synchronization issues: but it looks like many of us are ready to make that leap in pursuit of efficiency, but this guideline would make the protocol insecure! In fact, I recall Hugh raising this issue at a meeting once, and was convinced only after hearing the assertion that unverifiable packets would be dropped! On your wording: when you say optional, do you mean "MAY"? I would stick to the current specification: receivers MUST drop packets if they cannot verify them. regards, Lakshminath >5/ Discard if a packet cannot be authenticated should be optional = Agreed Bob Briscoe wrote: > Mark, > > At 23:49 12/09/2004, Mark Baugher wrote: > >hi Bob > > Just to recap this thread: We agreed to make the group MAC a > >RECOMMENDED feature rather than required. We'll use you editorial > >comments as a guide when we make the next update to the specification. > >And we'll look forward to reviewing DoS points in a subsequent revision > >of the base TESLA I-D. > > Yup. > > I've quoted my five original points below with the resolutions so far, as > far as I understand them. > > >1/ Key index field is redundant with SRTP > = Debate current on list (Replies to that thread not this, pls) > > >2/ Non-TESLA group authentication to protect against DoS should be > >optional > = Agreed should be RECOMMENDED > > >3/ Non-TESLA group authentication to protect against DoS is redundant > = Related to point 2/ and depends on write-up of alternative DoS > protection > in a new TESLA-intro (I sent a new draft to my co-authors last Fri for > sanity checking - should be on the msec list soon). > > >4/ No need to include the key index, i, in the TESLA authenticated > >portion > = Agreed > > >5/ Discard if a packet cannot be authenticated should be optional > = Agreed > > >Nits > = To be considered in next draft. > > Cheers > > > Bob > > >thanks, Mark > >On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote: > > > >>Mark, > >> > >>At 18:49 30/08/2004, Mark Baugher wrote: > >>>Bob, > >>> I reply to many of your points below, but here is something I'd > like > >>>for you and your co-authors to consider: Apart from reusing the RTP > >>>timestamp field the issue you raise in point 3 is a general TESLA > >>>issue > >>>and not an SRTP-TESLA issue. I think this is also true for guidance > >>>on > >>>the use or non-use of a group MAC, which is related to your point 3. > >>>I'd like to see these points treated in a general way so why not > >>>critique the base TESLA spec on this point and not SRTP-TESLA? > >> > >>Yup, for the DoS prevention, Ran Canetti has proposed we need to add a > >>more formal DoS mitigation section to TESLA-intro. > >> > >>This mail thread just goes to show how getting specific about a > >>protocol (SRTP) feeds back to the generic description. It was only > >>when we got to the specifics that the issues became clear. I'll stop > >>pestering you for a while on point 3/ (DoS prevention). > >> > >>On use/non-use of group MAC, TESLA-intro won't MANDATE anything. It's > >>informational. > >> > >>More inline. > >> > >>> More below... > >>>On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: > >>>... > >>>>Having thought about it, I will be stronger than the last mail and > >>>>say > >>>>a group MAC will provide barely any additional protection in most > >>>>circumstances so should not be the default. The logic of using a > >>>>group > >>>>MAC with TESLA looks like this: > >>>> > >>>> Sender's level of trust in group members not to spoof packets > >>>> | using a group key? | > >>>> Low High > >>>> | | > >>>> Use source authentication (ie TESLA). Use group > >>>>authentication. > >>>> | > >>>> TESLA is vulnerable to DoS filling buffer > >>>> until delayed auth > >>>> | > >>>> Use group authentication alongside TESLA > >>>> (as in current SRTP draft) > >>>> > >>>>I hope this diagram helps highlight the broken logic. > >>>>Group authentication is being MANDATED in the SRTP draft in a > >>>>scenario > >>>>which only ever arises where the group isn't trusted. > >>> > >>>Trusted to do or not do what? I think in this case, "trusted" means > >>>"trusted not to launch a denial of service attack against the group." > >>>There is also "trusted not to capture a disclosed key to successfully > >>>impersonate a group sender." Further, there is "trusted not to > >>>disclose a group key" - and so on. Treating something as complicated > >>>as this as "high" or "low" is not persuading me, personally. > >> > >>I started out the diag making clear the trust context, but yes, it got > >>munged into unspecified trust in the explanatory para after. SOrry. I > >>think it best if I write all the applicability stuff into a new DoS > >>sectino in the TESLA-intro, then we can have this debate with some > >>clarity. > >> > >>I hope to do this while the issue is fresh - next few days, but... > >> > >> > >>>>dding group authentication to TESLA only provides any additional > >>>>value > >>>>for the narrow range of scenarios where group members aren't trusted > >>>>enough to use group authentication alone, but they are trusted > >>>>sufficiently that group authentication might detect some DoS attacks > >>>>- > >>>>pretty slim odds. Worth allowing as an option, but surely not > >>>>MANDATING. > >>> > >>>You see a waste of time and bandwidth for protection that is > >>>superfluous. I see a relatively cheap way to keep a group protected > >>>against anyone running a kiddie script who decides to send a burst of > >>>packets and overflow members' buffers. Let's gather some more opinion > >>>from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. > >> > >>The S/KEY-like scheme in point 3/ is an alternative, but it's now > >>different to what I described following Adrian Perrig knocking it > >>down,... me fixing it,... then Adrian agreeing it's now OK. It's now a > >>good option for fixed or nearly-fixed packet rate (eg audio), but > >>needs applicability carefully explaining for highly variable packet > >>rate (eg video). > >> > >>I've agreed to document three DoS mitigation possibilities in a next > >>TESLA-intro draft: > >>* check that the disclosed key fits the chain (simple but weak - > >>always worth doing) > >>* group MAC > >>* disclose & use new key each packet > >> > >>I think it's best to wait for that before the debate on what > >>defaults/options/transforms there should be in SRTP-TESLA. > >> > >>I've split the remaining reply into separate threads for each numbered > >>issue I raised at least those still up for debate, as requested. THey > >>are all orthogonal. > >> > >> > >> > >>>>>>2/ Non-TESLA group authentication to protect against DoS should be > >>>>>>optional > >>>>>>------------------------------------------------------------------- > >>>>>>-- -- ---- > >>>>>>The immediate authentication provided by your non-TESLA group > >>>>>>authentication only protects against DoS by non-group members. It > >>>>>>should be RECOMMENDED not REQUIRED (section 7). > >>>>> > >>>>>I think that this point should be resolved in the base TESLA > >>>>>specification, i.e. I don't think there is anything that is > >>>>>SRTP-specific to this point. But we did not treat it that way in > >>>>>SRTP-TESLA, and that's probably my fault. Nonetheless, I think it > >>>>>should be REQUIRED in base TESLA. > >>>> > >>>>Currently section 5 (security considerations) of the TESLA-intro > >>>>mentions group authentication as one possible way of preventing > >>>>flooding attacks during the key disclosure delay. But it doesn't > >>>>MANDATE it. I'm simply taking issue with group authentication being > >>>>MANDATED in SRTP-TESLA, as I don't think it's effective in many > >>>>(most?) scenarios, making it unnecessary overhead. > >>>> > >>>>I have no problem with making a group MAC optional for scenarios > >>>>where > >>>>it does improve matters. > >>> > >>>I don't have a lot of religious fervor on the topic either though I > >>>like to avoid options in security protocols whenever possible. What > >>>seemed fairly obvious to me obviously seems wasteful to you. I'd like > >>>to discuss this further in a separate thread. We are really > >>>discussing > >>>a security requirement for protecting groups. > >>>... > >>> > >>>> > >>>>Sorry, history was a distracting word. I meant likelihood. Imagine a > >>>>video conf between senior execs of competing companies, or between > >>>>representatives of mutually distrusting governments. They don't trust > >>>>each other not to spoof what the other parties are saying, but they > >>>>have no likelihood of one launching a flooding attack on the other > >>>>(e.g. the whole thing is over a joint VPN). They need group > >>>>authentication like a phish needs a bicycle. So why MANDATE it? > >>> > >>>We are beating this to death and confusing one another. The > >>>participants would not launch the flooding attack; an interloper would > >>>do it. If it's over a VPN, then the attack seems very unlikely - as > >>>is > >>>source spoofing in a small teleconference, for that matter. > >>>... > >>>> > >>>>>relies upon the fact that memory gets tied up while > >>>>>packets are buffered awaiting authentication. In this case, there > >>>>>is > >>>>>no buffering of multiple packets, just one packet during the > >>>>>disclosure > >>>>>interval. Do I understand you correctly? > >>>> > >>>>No. The disclosure *interval* (delay) still spans multiple packets. > >>>>The new feature depends on each key now only ever being *disclosed* > >>>>once, rather than the same key being disclosed repeatedly as it was > >>>>when there were multiple packets in the same TESLA time interval. > >>> > >>>Before we go any further into this, I'd like to understand why this > >>>disclosure scheme needs to be considered only for SRTP. You mention > >>>below that you also think that it belongs in the base TESLA > >>>specification and that you have raised the issue with your co-authors? > >>>I think the TESLA co-authors might want to consider discussing this on > >>>the list. That sounds better than treating SRTP-TESLA as the poster > >>>child for something that was maybe overlooked in the base TESLA > >>>document. > >>> > >>>I just got back from some personal time off and am working through > >>>several hundred messages - I prioritized yours. It would be a more > >>>efficient discussion to discuss this with the TESLA authors - on the > >>>msec list if possible. > >>> > >>>> > >>>>As soon as a packet arrives, the disclosed key in it now has two > >>>>purposes: > >>>>- it's original TESLA purpose: to verify a packet received some time > >>>>previously > >>>>- to immediately show the receiver that the sender of this packet > >>>>knew > >>>>the next key back along the hash chain which is now only ever > >>>>*disclosed* once > >>>> > >>>>So if more packets are received that *disclose* the same key, the > >>>>receiver can assume (at least until the delayed TESLA verification) > >>>>that only the first packet to disclose each key was genuine. > >>>> > >>>>If a network element is compromised, an attacker can discover the > >>>>next > >>>>disclosed key and overtake or replace a genuine packet with many > >>>>others. But the receiver can still immediately discard all but the > >>>>first to arrive, protecting itself from memory overflow. > >>>> > >>>>So the scheme has the following properties: > >>>>- The receiver will never buffer more than one packet per packet sent > >>>>by the genuine sender (so the receiver's buffer fill rate is still > >>>>clocked by the party that reveals each new key backwards in the > >>>>chain). > >>>>- As each key is later disclosed, TESLA can do delayed verification > >>>>of > >>>>these stored packets. > >>>> - if they pass delayed verfication, the messages must be genuine > >>>> - if they fail delayed verfication, the messages must not have > been > >>>>genuine > >>>>- The true message will have been lost in the latter case. But, then > >>>>if an attacker can compromise a network element, it can discard the > >>>>true messages anyway (a group MAC can't prevent this either ;) > >>>> > >>>>I need to fully document this. There are some corner cases not > >>>>covered > >>>>by the above. I've given an outline later. Obviously, this DoS > >>>>protection idea hasn't had the same peer-review as TESLA, except it > >>>>is > >>>>essentially just S/KEY, which has had ample peer review (but perhaps > >>>>not in a group setting). > >>> > >>>This sounds promising to me, but I would like to see the document - I > >>>have not read the one you sent me yet. And I would like to hear what > >>>the other TESLA authors have to say about it. > >>> > >>>... > >>>>>If so, why > >>>>>not put this in the core TESLA specification. I'd say that if it > >>>>>belongs in SRTP-TESLA, then it belongs in the core specification. > >>>>>No? > >>>> > >>>>You are absolutely correct. > >>>> > >>>>We (the co-authors of the TESLA base spec) are discussing this > >>>>off-line right now. It's my fault we didn't reach closure on it > >>>>before > >>>>TESLA got this far. I was originally pushing this as an option, but I > >>>>think I never quite got myself understood. Somewhere in the mists of > >>>>time I gave up. I've been taking a back seat on the TESLA work until > >>>>just recently, so my brain obviously wasn't in gear when reviewing > >>>>drafts. I forgot I'd got this option to attack the DoS problem. It > >>>>was > >>>>only through reveiwing the SRTP draft that the technique came back to > >>>>me. Now, the more I argue about it, the better I think it is. > >>>> > >>>>However, it's not out of the woods yet. My co-authors are trying to > >>>>break it. I believe I've defended it in the case of variable packet > >>>>rate and packet misordering. But I'm expecting more attempts to break > >>>>it (and, of course, anyone on this list is welcome to try as well). > >>>> > >>>>If it comes out intact, you should see text on it shortly. Otherwise, > >>>>I guess the TESLA base spec will stay as it is. > >>> > >>>And this sizable email exchange would be in vain :?) > >>> > >>>... > >>>>>>BTW, it should be pointed out that the verification algo should > >>>>>>check > >>>>>>the key index is within an expected range before using it (e.g. > >>>>>>only > >>>>>>a > >>>>>>small increment above the last highest verified key index seen). > >>>>>>Otherwise, an attacker can tamper with this field to lead all > >>>>>>receivers to run millions of hash operations unnecessarily. I > >>>>>>prefer > >>>>>>to call it a key-index *hint*, to remind me not to rely on it being > >>>>>>correct. > >>>>> > >>>>>This sounds like an argument for keeping the MAC. > >>>> > >>>>No. It is an argument for watching that it doesn't appear to imply > >>>>packets are extremely re-ordered (e.g. it must be no more than, say, > >>>>64 different from the previous highest index, cf the SRTP replay > >>>>protection window). You /could/ use a group MAC to do an initial test > >>>>of its integrity, but why waste 10 octets when you can do a test that > >>>>uses none? And this would only work if you trusted the group members > >>>>(recall, we are using TESLA because we don't trust them). > >>> > >>>The group MAC was originally 4 bytes and I need to check with > >>>Elisabetta to find out why it is now 10. I don't see why it needs to > >>>be larger than 4 bytes for group MAC purposes. If we manage to > >>>obviate > >>>the need for group MACs in TESLA, then it can be zero bytes and I'll > >>>be > >>>perfectly happy. > >>>> > >>>>The key index is implicitly authenticated (similar to the implicit > >>>>header authentication in section 9.5.2 of the SRTP RFC) because the > >>>>TESLA MAC depends on it. If the key index is tampered with, the > >>>>authentication test will fail as it should. > >>> > >>>Ok. > >>>... > >>>>> > >>>>>We'll refer to your editorial comments at the next revision. > >>>> > >>>>I've added a couple more below... > >>> > >>>Good. How do you feel about my proposal to consider the proposed use > >>>of the RTP timestamp field separately from the group MAC. And treat > >>>the group MAC as a related question to your point 3 scheme? > >> > >>Yup. Done. > >> > >>Cheers > >> > >> > >>Bob > >> > >> > >>_______________________________________________________________________ > _____ > >>Bob Briscoe, Networks Research Centre, BT > >>Research > >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > >>645196 > >> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://six.pairlist.net/mailman/listinfo/msec > > > >____________________________________________________________________________ > > >Bob Briscoe, Networks Research Centre, BT > Research > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Sep 14 15:27:09 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07479 for ; Tue, 14 Sep 2004 15:27:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5D17C8D16C; Tue, 14 Sep 2004 15:27:09 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C8FD48D0B4 for ; Tue, 14 Sep 2004 15:27:07 -0400 (EDT) Received: (qmail 24330 invoked by uid 3269); 14 Sep 2004 19:27:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24327 invoked from network); 14 Sep 2004 19:27:07 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 14 Sep 2004 19:27:07 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 Sep 2004 12:27:49 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn4-290.cisco.com [10.21.81.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8EJPpxl019689; Tue, 14 Sep 2004 12:27:03 -0700 (PDT) In-Reply-To: References: <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040901174602.01a9d630@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040914174749.01aaa9d8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Tue, 14 Sep 2004 12:24:40 -0700 To: Mark Baugher X-Mailer: Apple Mail (2.619) Cc: Bob Briscoe , elisabetta.carrara@ericsson.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: > hi Bob > > On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote: >> > ... >> >> >>> 5/ Discard if a packet cannot be authenticated should be optional >> = Agreed > > I did not sign up for this one - or at least I did not mean to. I'd > like to discuss this some more. Personally, I want to limit options > wherever possible and this is the second option (including making the > group optional) sorry, I meant "group MAC optional" Mark > that you have proposed. I don't think we necessarily want to add this > particular option and would like to hear what others have to say on > the matter. > > thanks, Mark >> >>> Nits >> = To be considered in next draft. >> >> Cheers >> >> >> Bob >> >>> thanks, Mark >>> On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote: >>> >>>> Mark, >>>> >>>> At 18:49 30/08/2004, Mark Baugher wrote: >>>>> Bob, >>>>> I reply to many of your points below, but here is something I'd >>>>> like >>>>> for you and your co-authors to consider: Apart from reusing the >>>>> RTP >>>>> timestamp field the issue you raise in point 3 is a general TESLA >>>>> issue >>>>> and not an SRTP-TESLA issue. I think this is also true for >>>>> guidance >>>>> on >>>>> the use or non-use of a group MAC, which is related to your point >>>>> 3. >>>>> I'd like to see these points treated in a general way so why not >>>>> critique the base TESLA spec on this point and not SRTP-TESLA? >>>> >>>> Yup, for the DoS prevention, Ran Canetti has proposed we need to >>>> add a >>>> more formal DoS mitigation section to TESLA-intro. >>>> >>>> This mail thread just goes to show how getting specific about a >>>> protocol (SRTP) feeds back to the generic description. It was only >>>> when we got to the specifics that the issues became clear. I'll stop >>>> pestering you for a while on point 3/ (DoS prevention). >>>> >>>> On use/non-use of group MAC, TESLA-intro won't MANDATE anything. >>>> It's >>>> informational. >>>> >>>> More inline. >>>> >>>>> More below... >>>>> On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: >>>>> ... >>>>>> Having thought about it, I will be stronger than the last mail and >>>>>> say >>>>>> a group MAC will provide barely any additional protection in most >>>>>> circumstances so should not be the default. The logic of using a >>>>>> group >>>>>> MAC with TESLA looks like this: >>>>>> >>>>>> Sender's level of trust in group members not to spoof packets >>>>>> | using a group key? | >>>>>> Low High >>>>>> | | >>>>>> Use source authentication (ie TESLA). Use group >>>>>> authentication. >>>>>> | >>>>>> TESLA is vulnerable to DoS filling buffer >>>>>> until delayed auth >>>>>> | >>>>>> Use group authentication alongside TESLA >>>>>> (as in current SRTP draft) >>>>>> >>>>>> I hope this diagram helps highlight the broken logic. >>>>>> Group authentication is being MANDATED in the SRTP draft in a >>>>>> scenario >>>>>> which only ever arises where the group isn't trusted. >>>>> >>>>> Trusted to do or not do what? I think in this case, "trusted" >>>>> means >>>>> "trusted not to launch a denial of service attack against the >>>>> group." >>>>> There is also "trusted not to capture a disclosed key to >>>>> successfully >>>>> impersonate a group sender." Further, there is "trusted not to >>>>> disclose a group key" - and so on. Treating something as >>>>> complicated >>>>> as this as "high" or "low" is not persuading me, personally. >>>> >>>> I started out the diag making clear the trust context, but yes, it >>>> got >>>> munged into unspecified trust in the explanatory para after. SOrry. >>>> I >>>> think it best if I write all the applicability stuff into a new DoS >>>> sectino in the TESLA-intro, then we can have this debate with some >>>> clarity. >>>> >>>> I hope to do this while the issue is fresh - next few days, but... >>>> >>>> >>>>>> dding group authentication to TESLA only provides any additional >>>>>> value >>>>>> for the narrow range of scenarios where group members aren't >>>>>> trusted >>>>>> enough to use group authentication alone, but they are trusted >>>>>> sufficiently that group authentication might detect some DoS >>>>>> attacks >>>>>> - >>>>>> pretty slim odds. Worth allowing as an option, but surely not >>>>>> MANDATING. >>>>> >>>>> You see a waste of time and bandwidth for protection that is >>>>> superfluous. I see a relatively cheap way to keep a group >>>>> protected >>>>> against anyone running a kiddie script who decides to send a burst >>>>> of >>>>> packets and overflow members' buffers. Let's gather some more >>>>> opinion >>>>> from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, >>>>> BELOW. >>>> >>>> The S/KEY-like scheme in point 3/ is an alternative, but it's now >>>> different to what I described following Adrian Perrig knocking it >>>> down,... me fixing it,... then Adrian agreeing it's now OK. It's >>>> now a >>>> good option for fixed or nearly-fixed packet rate (eg audio), but >>>> needs applicability carefully explaining for highly variable packet >>>> rate (eg video). >>>> >>>> I've agreed to document three DoS mitigation possibilities in a next >>>> TESLA-intro draft: >>>> * check that the disclosed key fits the chain (simple but weak - >>>> always worth doing) >>>> * group MAC >>>> * disclose & use new key each packet >>>> >>>> I think it's best to wait for that before the debate on what >>>> defaults/options/transforms there should be in SRTP-TESLA. >>>> >>>> I've split the remaining reply into separate threads for each >>>> numbered >>>> issue I raised at least those still up for debate, as requested. >>>> THey >>>> are all orthogonal. >>>> >>>> >>>> >>>>>>>> 2/ Non-TESLA group authentication to protect against DoS should >>>>>>>> be >>>>>>>> optional >>>>>>>> ---------------------------------------------------------------- >>>>>>>> --- -- -- ---- >>>>>>>> The immediate authentication provided by your non-TESLA group >>>>>>>> authentication only protects against DoS by non-group members. >>>>>>>> It >>>>>>>> should be RECOMMENDED not REQUIRED (section 7). >>>>>>> >>>>>>> I think that this point should be resolved in the base TESLA >>>>>>> specification, i.e. I don't think there is anything that is >>>>>>> SRTP-specific to this point. But we did not treat it that way in >>>>>>> SRTP-TESLA, and that's probably my fault. Nonetheless, I think >>>>>>> it >>>>>>> should be REQUIRED in base TESLA. >>>>>> >>>>>> Currently section 5 (security considerations) of the TESLA-intro >>>>>> mentions group authentication as one possible way of preventing >>>>>> flooding attacks during the key disclosure delay. But it doesn't >>>>>> MANDATE it. I'm simply taking issue with group authentication >>>>>> being >>>>>> MANDATED in SRTP-TESLA, as I don't think it's effective in many >>>>>> (most?) scenarios, making it unnecessary overhead. >>>>>> >>>>>> I have no problem with making a group MAC optional for scenarios >>>>>> where >>>>>> it does improve matters. >>>>> >>>>> I don't have a lot of religious fervor on the topic either though I >>>>> like to avoid options in security protocols whenever possible. >>>>> What >>>>> seemed fairly obvious to me obviously seems wasteful to you. I'd >>>>> like >>>>> to discuss this further in a separate thread. We are really >>>>> discussing >>>>> a security requirement for protecting groups. >>>>> ... >>>>> >>>>>> >>>>>> Sorry, history was a distracting word. I meant likelihood. >>>>>> Imagine a >>>>>> video conf between senior execs of competing companies, or between >>>>>> representatives of mutually distrusting governments. They don't >>>>>> trust >>>>>> each other not to spoof what the other parties are saying, but >>>>>> they >>>>>> have no likelihood of one launching a flooding attack on the other >>>>>> (e.g. the whole thing is over a joint VPN). They need group >>>>>> authentication like a phish needs a bicycle. So why MANDATE it? >>>>> >>>>> We are beating this to death and confusing one another. The >>>>> participants would not launch the flooding attack; an interloper >>>>> would >>>>> do it. If it's over a VPN, then the attack seems very unlikely - >>>>> as >>>>> is >>>>> source spoofing in a small teleconference, for that matter. >>>>> ... >>>>>> >>>>>>> relies upon the fact that memory gets tied up while >>>>>>> packets are buffered awaiting authentication. In this case, >>>>>>> there >>>>>>> is >>>>>>> no buffering of multiple packets, just one packet during the >>>>>>> disclosure >>>>>>> interval. Do I understand you correctly? >>>>>> >>>>>> No. The disclosure *interval* (delay) still spans multiple >>>>>> packets. >>>>>> The new feature depends on each key now only ever being >>>>>> *disclosed* >>>>>> once, rather than the same key being disclosed repeatedly as it >>>>>> was >>>>>> when there were multiple packets in the same TESLA time interval. >>>>> >>>>> Before we go any further into this, I'd like to understand why this >>>>> disclosure scheme needs to be considered only for SRTP. You >>>>> mention >>>>> below that you also think that it belongs in the base TESLA >>>>> specification and that you have raised the issue with your >>>>> co-authors? >>>>> I think the TESLA co-authors might want to consider discussing >>>>> this on >>>>> the list. That sounds better than treating SRTP-TESLA as the >>>>> poster >>>>> child for something that was maybe overlooked in the base TESLA >>>>> document. >>>>> >>>>> I just got back from some personal time off and am working through >>>>> several hundred messages - I prioritized yours. It would be a more >>>>> efficient discussion to discuss this with the TESLA authors - on >>>>> the >>>>> msec list if possible. >>>>> >>>>>> >>>>>> As soon as a packet arrives, the disclosed key in it now has two >>>>>> purposes: >>>>>> - it's original TESLA purpose: to verify a packet received some >>>>>> time >>>>>> previously >>>>>> - to immediately show the receiver that the sender of this packet >>>>>> knew >>>>>> the next key back along the hash chain which is now only ever >>>>>> *disclosed* once >>>>>> >>>>>> So if more packets are received that *disclose* the same key, the >>>>>> receiver can assume (at least until the delayed TESLA >>>>>> verification) >>>>>> that only the first packet to disclose each key was genuine. >>>>>> >>>>>> If a network element is compromised, an attacker can discover the >>>>>> next >>>>>> disclosed key and overtake or replace a genuine packet with many >>>>>> others. But the receiver can still immediately discard all but the >>>>>> first to arrive, protecting itself from memory overflow. >>>>>> >>>>>> So the scheme has the following properties: >>>>>> - The receiver will never buffer more than one packet per packet >>>>>> sent >>>>>> by the genuine sender (so the receiver's buffer fill rate is still >>>>>> clocked by the party that reveals each new key backwards in the >>>>>> chain). >>>>>> - As each key is later disclosed, TESLA can do delayed >>>>>> verification >>>>>> of >>>>>> these stored packets. >>>>>> - if they pass delayed verfication, the messages must be genuine >>>>>> - if they fail delayed verfication, the messages must not have >>>>>> been >>>>>> genuine >>>>>> - The true message will have been lost in the latter case. But, >>>>>> then >>>>>> if an attacker can compromise a network element, it can discard >>>>>> the >>>>>> true messages anyway (a group MAC can't prevent this either ;) >>>>>> >>>>>> I need to fully document this. There are some corner cases not >>>>>> covered >>>>>> by the above. I've given an outline later. Obviously, this DoS >>>>>> protection idea hasn't had the same peer-review as TESLA, except >>>>>> it >>>>>> is >>>>>> essentially just S/KEY, which has had ample peer review (but >>>>>> perhaps >>>>>> not in a group setting). >>>>> >>>>> This sounds promising to me, but I would like to see the document >>>>> - I >>>>> have not read the one you sent me yet. And I would like to hear >>>>> what >>>>> the other TESLA authors have to say about it. >>>>> >>>>> ... >>>>>>> If so, why >>>>>>> not put this in the core TESLA specification. I'd say that if it >>>>>>> belongs in SRTP-TESLA, then it belongs in the core specification. >>>>>>> No? >>>>>> >>>>>> You are absolutely correct. >>>>>> >>>>>> We (the co-authors of the TESLA base spec) are discussing this >>>>>> off-line right now. It's my fault we didn't reach closure on it >>>>>> before >>>>>> TESLA got this far. I was originally pushing this as an option, >>>>>> but I >>>>>> think I never quite got myself understood. Somewhere in the mists >>>>>> of >>>>>> time I gave up. I've been taking a back seat on the TESLA work >>>>>> until >>>>>> just recently, so my brain obviously wasn't in gear when reviewing >>>>>> drafts. I forgot I'd got this option to attack the DoS problem. It >>>>>> was >>>>>> only through reveiwing the SRTP draft that the technique came >>>>>> back to >>>>>> me. Now, the more I argue about it, the better I think it is. >>>>>> >>>>>> However, it's not out of the woods yet. My co-authors are trying >>>>>> to >>>>>> break it. I believe I've defended it in the case of variable >>>>>> packet >>>>>> rate and packet misordering. But I'm expecting more attempts to >>>>>> break >>>>>> it (and, of course, anyone on this list is welcome to try as >>>>>> well). >>>>>> >>>>>> If it comes out intact, you should see text on it shortly. >>>>>> Otherwise, >>>>>> I guess the TESLA base spec will stay as it is. >>>>> >>>>> And this sizable email exchange would be in vain :?) >>>>> >>>>> ... >>>>>>>> BTW, it should be pointed out that the verification algo should >>>>>>>> check >>>>>>>> the key index is within an expected range before using it (e.g. >>>>>>>> only >>>>>>>> a >>>>>>>> small increment above the last highest verified key index seen). >>>>>>>> Otherwise, an attacker can tamper with this field to lead all >>>>>>>> receivers to run millions of hash operations unnecessarily. I >>>>>>>> prefer >>>>>>>> to call it a key-index *hint*, to remind me not to rely on it >>>>>>>> being >>>>>>>> correct. >>>>>>> >>>>>>> This sounds like an argument for keeping the MAC. >>>>>> >>>>>> No. It is an argument for watching that it doesn't appear to imply >>>>>> packets are extremely re-ordered (e.g. it must be no more than, >>>>>> say, >>>>>> 64 different from the previous highest index, cf the SRTP replay >>>>>> protection window). You /could/ use a group MAC to do an initial >>>>>> test >>>>>> of its integrity, but why waste 10 octets when you can do a test >>>>>> that >>>>>> uses none? And this would only work if you trusted the group >>>>>> members >>>>>> (recall, we are using TESLA because we don't trust them). >>>>> >>>>> The group MAC was originally 4 bytes and I need to check with >>>>> Elisabetta to find out why it is now 10. I don't see why it needs >>>>> to >>>>> be larger than 4 bytes for group MAC purposes. If we manage to >>>>> obviate >>>>> the need for group MACs in TESLA, then it can be zero bytes and >>>>> I'll >>>>> be >>>>> perfectly happy. >>>>>> >>>>>> The key index is implicitly authenticated (similar to the implicit >>>>>> header authentication in section 9.5.2 of the SRTP RFC) because >>>>>> the >>>>>> TESLA MAC depends on it. If the key index is tampered with, the >>>>>> authentication test will fail as it should. >>>>> >>>>> Ok. >>>>> ... >>>>>>> >>>>>>> We'll refer to your editorial comments at the next revision. >>>>>> >>>>>> I've added a couple more below... >>>>> >>>>> Good. How do you feel about my proposal to consider the proposed >>>>> use >>>>> of the RTP timestamp field separately from the group MAC. And >>>>> treat >>>>> the group MAC as a related question to your point 3 scheme? >>>> >>>> Yup. Done. >>>> >>>> Cheers >>>> >>>> >>>> Bob >>>> >>>> >>>> ____________________________________________________________________ >>>> ___ _____ >>>> Bob Briscoe, Networks Research Centre, BT >>>> Research >>>> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 >>>> 1473 >>>> 645196 >>>> >>>> _______________________________________________ >>>> msec mailing list >>>> msec@securemulticast.org >>>> http://six.pairlist.net/mailman/listinfo/msec >>> >>> _____________________________________________________________________ >>> _______ >>> Bob Briscoe, Networks Research Centre, BT >>> Research >>> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 >>> 1473 645196 >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Sep 15 04:06:31 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10598 for ; Wed, 15 Sep 2004 04:06:31 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 98CDE8D546; Wed, 15 Sep 2004 04:06:32 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 389038D541 for ; Wed, 15 Sep 2004 04:06:31 -0400 (EDT) Received: (qmail 89881 invoked by uid 3269); 15 Sep 2004 08:06:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89865 invoked from network); 15 Sep 2004 08:06:22 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 15 Sep 2004 08:06:22 -0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8F86LAh017793 for ; Wed, 15 Sep 2004 10:06:21 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 10:06:21 +0200 Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Sep 2004 10:06:21 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BC5E0@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: "'Dondeti, Lakshminath'" , Bob Briscoe Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Wed, 15 Sep 2004 09:56:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Sep 2004 08:06:21.0117 (UTC) FILETIME=[E2D296D0:01C49AFA] Cc: Mark Baugher , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi I share Lakshminath's view. Cheers /E > -----Original Message----- > From: Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com] > Sent: den 14 september 2004 21:08 > To: Bob Briscoe > Cc: Mark Baugher; Elisabetta Carrara (KI/EAB); > msec@securemulticast.org > Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) > > > Hi Bob, > > I am not sure there was consensus on issue #5 below. I don't > think it > is a good idea to allow a packet to be considered > authenticated, when a > receiver is not sure about it. Historically speaking, there > were a lot > of doubts on TESLA with the time synchronization issues: but it looks > like many of us are ready to make that leap in pursuit of efficiency, > but this guideline would make the protocol insecure! > > In fact, I recall Hugh raising this issue at a meeting once, and was > convinced only after hearing the assertion that unverifiable packets > would be dropped! > > On your wording: when you say optional, do you mean "MAY"? I would > stick to the current specification: receivers MUST drop > packets if they > cannot verify them. > > regards, > Lakshminath > > >5/ Discard if a packet cannot be authenticated should be optional > = Agreed > > > > Bob Briscoe wrote: > > > Mark, > > > > At 23:49 12/09/2004, Mark Baugher wrote: > > >hi Bob > > > Just to recap this thread: We agreed to make the group MAC a > > >RECOMMENDED feature rather than required. We'll use you editorial > > >comments as a guide when we make the next update to the > specification. > > >And we'll look forward to reviewing DoS points in a > subsequent revision > > >of the base TESLA I-D. > > > > Yup. > > > > I've quoted my five original points below with the > resolutions so far, as > > far as I understand them. > > > > >1/ Key index field is redundant with SRTP > > = Debate current on list (Replies to that thread not this, pls) > > > > >2/ Non-TESLA group authentication to protect against DoS should be > > >optional > > = Agreed should be RECOMMENDED > > > > >3/ Non-TESLA group authentication to protect against DoS > is redundant > > = Related to point 2/ and depends on write-up of alternative DoS > > protection > > in a new TESLA-intro (I sent a new draft to my co-authors > last Fri for > > sanity checking - should be on the msec list soon). > > > > >4/ No need to include the key index, i, in the TESLA authenticated > > >portion > > = Agreed > > > > >5/ Discard if a packet cannot be authenticated should be optional > > = Agreed > > > > >Nits > > = To be considered in next draft. > > > > Cheers > > > > > > Bob > > > > >thanks, Mark > > >On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote: > > > > > >>Mark, > > >> > > >>At 18:49 30/08/2004, Mark Baugher wrote: > > >>>Bob, > > >>> I reply to many of your points below, but here is > something I'd > > like > > >>>for you and your co-authors to consider: Apart from > reusing the RTP > > >>>timestamp field the issue you raise in point 3 is a general TESLA > > >>>issue > > >>>and not an SRTP-TESLA issue. I think this is also true > for guidance > > >>>on > > >>>the use or non-use of a group MAC, which is related to > your point 3. > > >>>I'd like to see these points treated in a general way so why not > > >>>critique the base TESLA spec on this point and not SRTP-TESLA? > > >> > > >>Yup, for the DoS prevention, Ran Canetti has proposed we > need to add a > > >>more formal DoS mitigation section to TESLA-intro. > > >> > > >>This mail thread just goes to show how getting specific about a > > >>protocol (SRTP) feeds back to the generic description. It was only > > >>when we got to the specifics that the issues became > clear. I'll stop > > >>pestering you for a while on point 3/ (DoS prevention). > > >> > > >>On use/non-use of group MAC, TESLA-intro won't MANDATE > anything. It's > > >>informational. > > >> > > >>More inline. > > >> > > >>> More below... > > >>>On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: > > >>>... > > >>>>Having thought about it, I will be stronger than the > last mail and > > >>>>say > > >>>>a group MAC will provide barely any additional > protection in most > > >>>>circumstances so should not be the default. The logic of using a > > >>>>group > > >>>>MAC with TESLA looks like this: > > >>>> > > >>>> Sender's level of trust in group members not to > spoof packets > > >>>> | using a group key? | > > >>>> Low High > > >>>> | | > > >>>> Use source authentication (ie TESLA). Use group > > >>>>authentication. > > >>>> | > > >>>> TESLA is vulnerable to DoS filling buffer > > >>>> until delayed auth > > >>>> | > > >>>> Use group authentication alongside TESLA > > >>>> (as in current SRTP draft) > > >>>> > > >>>>I hope this diagram helps highlight the broken logic. > > >>>>Group authentication is being MANDATED in the SRTP draft in a > > >>>>scenario > > >>>>which only ever arises where the group isn't trusted. > > >>> > > >>>Trusted to do or not do what? I think in this case, > "trusted" means > > >>>"trusted not to launch a denial of service attack > against the group." > > >>>There is also "trusted not to capture a disclosed key to > successfully > > >>>impersonate a group sender." Further, there is "trusted not to > > >>>disclose a group key" - and so on. Treating something > as complicated > > >>>as this as "high" or "low" is not persuading me, personally. > > >> > > >>I started out the diag making clear the trust context, > but yes, it got > > >>munged into unspecified trust in the explanatory para > after. SOrry. I > > >>think it best if I write all the applicability stuff into > a new DoS > > >>sectino in the TESLA-intro, then we can have this debate with some > > >>clarity. > > >> > > >>I hope to do this while the issue is fresh - next few days, but... > > >> > > >> > > >>>>dding group authentication to TESLA only provides any additional > > >>>>value > > >>>>for the narrow range of scenarios where group members > aren't trusted > > >>>>enough to use group authentication alone, but they are trusted > > >>>>sufficiently that group authentication might detect > some DoS attacks > > >>>>- > > >>>>pretty slim odds. Worth allowing as an option, but surely not > > >>>>MANDATING. > > >>> > > >>>You see a waste of time and bandwidth for protection that is > > >>>superfluous. I see a relatively cheap way to keep a > group protected > > >>>against anyone running a kiddie script who decides to > send a burst of > > >>>packets and overflow members' buffers. Let's gather > some more opinion > > >>>from msec on this point IF IT IS NOT MADE MOOT BY YOUR > POINT 3, BELOW. > > >> > > >>The S/KEY-like scheme in point 3/ is an alternative, but it's now > > >>different to what I described following Adrian Perrig knocking it > > >>down,... me fixing it,... then Adrian agreeing it's now > OK. It's now a > > >>good option for fixed or nearly-fixed packet rate (eg audio), but > > >>needs applicability carefully explaining for highly > variable packet > > >>rate (eg video). > > >> > > >>I've agreed to document three DoS mitigation > possibilities in a next > > >>TESLA-intro draft: > > >>* check that the disclosed key fits the chain (simple but weak - > > >>always worth doing) > > >>* group MAC > > >>* disclose & use new key each packet > > >> > > >>I think it's best to wait for that before the debate on what > > >>defaults/options/transforms there should be in SRTP-TESLA. > > >> > > >>I've split the remaining reply into separate threads for > each numbered > > >>issue I raised at least those still up for debate, as > requested. THey > > >>are all orthogonal. > > >> > > >> > > >> > > >>>>>>2/ Non-TESLA group authentication to protect against > DoS should be > > >>>>>>optional > > > >>>>>>-------------------------------------------------------- > ----------- > > >>>>>>-- -- ---- > > >>>>>>The immediate authentication provided by your non-TESLA group > > >>>>>>authentication only protects against DoS by non-group > members. It > > >>>>>>should be RECOMMENDED not REQUIRED (section 7). > > >>>>> > > >>>>>I think that this point should be resolved in the base TESLA > > >>>>>specification, i.e. I don't think there is anything that is > > >>>>>SRTP-specific to this point. But we did not treat it > that way in > > >>>>>SRTP-TESLA, and that's probably my fault. > Nonetheless, I think it > > >>>>>should be REQUIRED in base TESLA. > > >>>> > > >>>>Currently section 5 (security considerations) of the TESLA-intro > > >>>>mentions group authentication as one possible way of preventing > > >>>>flooding attacks during the key disclosure delay. But it doesn't > > >>>>MANDATE it. I'm simply taking issue with group > authentication being > > >>>>MANDATED in SRTP-TESLA, as I don't think it's effective in many > > >>>>(most?) scenarios, making it unnecessary overhead. > > >>>> > > >>>>I have no problem with making a group MAC optional for scenarios > > >>>>where > > >>>>it does improve matters. > > >>> > > >>>I don't have a lot of religious fervor on the topic > either though I > > >>>like to avoid options in security protocols whenever > possible. What > > >>>seemed fairly obvious to me obviously seems wasteful to > you. I'd like > > >>>to discuss this further in a separate thread. We are really > > >>>discussing > > >>>a security requirement for protecting groups. > > >>>... > > >>> > > >>>> > > >>>>Sorry, history was a distracting word. I meant > likelihood. Imagine a > > >>>>video conf between senior execs of competing companies, > or between > > >>>>representatives of mutually distrusting governments. > They don't trust > > >>>>each other not to spoof what the other parties are > saying, but they > > >>>>have no likelihood of one launching a flooding attack > on the other > > >>>>(e.g. the whole thing is over a joint VPN). They need group > > >>>>authentication like a phish needs a bicycle. So why MANDATE it? > > >>> > > >>>We are beating this to death and confusing one another. The > > >>>participants would not launch the flooding attack; an > interloper would > > >>>do it. If it's over a VPN, then the attack seems very > unlikely - as > > >>>is > > >>>source spoofing in a small teleconference, for that matter. > > >>>... > > >>>> > > >>>>>relies upon the fact that memory gets tied up while > > >>>>>packets are buffered awaiting authentication. In this > case, there > > >>>>>is > > >>>>>no buffering of multiple packets, just one packet during the > > >>>>>disclosure > > >>>>>interval. Do I understand you correctly? > > >>>> > > >>>>No. The disclosure *interval* (delay) still spans > multiple packets. > > >>>>The new feature depends on each key now only ever being > *disclosed* > > >>>>once, rather than the same key being disclosed > repeatedly as it was > > >>>>when there were multiple packets in the same TESLA time > interval. > > >>> > > >>>Before we go any further into this, I'd like to > understand why this > > >>>disclosure scheme needs to be considered only for SRTP. > You mention > > >>>below that you also think that it belongs in the base TESLA > > >>>specification and that you have raised the issue with > your co-authors? > > >>>I think the TESLA co-authors might want to consider > discussing this on > > >>>the list. That sounds better than treating SRTP-TESLA > as the poster > > >>>child for something that was maybe overlooked in the base TESLA > > >>>document. > > >>> > > >>>I just got back from some personal time off and am > working through > > >>>several hundred messages - I prioritized yours. It > would be a more > > >>>efficient discussion to discuss this with the TESLA > authors - on the > > >>>msec list if possible. > > >>> > > >>>> > > >>>>As soon as a packet arrives, the disclosed key in it now has two > > >>>>purposes: > > >>>>- it's original TESLA purpose: to verify a packet > received some time > > >>>>previously > > >>>>- to immediately show the receiver that the sender of > this packet > > >>>>knew > > >>>>the next key back along the hash chain which is now only ever > > >>>>*disclosed* once > > >>>> > > >>>>So if more packets are received that *disclose* the > same key, the > > >>>>receiver can assume (at least until the delayed TESLA > verification) > > >>>>that only the first packet to disclose each key was genuine. > > >>>> > > >>>>If a network element is compromised, an attacker can > discover the > > >>>>next > > >>>>disclosed key and overtake or replace a genuine packet with many > > >>>>others. But the receiver can still immediately discard > all but the > > >>>>first to arrive, protecting itself from memory overflow. > > >>>> > > >>>>So the scheme has the following properties: > > >>>>- The receiver will never buffer more than one packet > per packet sent > > >>>>by the genuine sender (so the receiver's buffer fill > rate is still > > >>>>clocked by the party that reveals each new key backwards in the > > >>>>chain). > > >>>>- As each key is later disclosed, TESLA can do delayed > verification > > >>>>of > > >>>>these stored packets. > > >>>> - if they pass delayed verfication, the messages > must be genuine > > >>>> - if they fail delayed verfication, the messages > must not have > > been > > >>>>genuine > > >>>>- The true message will have been lost in the latter > case. But, then > > >>>>if an attacker can compromise a network element, it can > discard the > > >>>>true messages anyway (a group MAC can't prevent this either ;) > > >>>> > > >>>>I need to fully document this. There are some corner cases not > > >>>>covered > > >>>>by the above. I've given an outline later. Obviously, this DoS > > >>>>protection idea hasn't had the same peer-review as > TESLA, except it > > >>>>is > > >>>>essentially just S/KEY, which has had ample peer review > (but perhaps > > >>>>not in a group setting). > > >>> > > >>>This sounds promising to me, but I would like to see the > document - I > > >>>have not read the one you sent me yet. And I would like > to hear what > > >>>the other TESLA authors have to say about it. > > >>> > > >>>... > > >>>>>If so, why > > >>>>>not put this in the core TESLA specification. I'd say > that if it > > >>>>>belongs in SRTP-TESLA, then it belongs in the core > specification. > > >>>>>No? > > >>>> > > >>>>You are absolutely correct. > > >>>> > > >>>>We (the co-authors of the TESLA base spec) are discussing this > > >>>>off-line right now. It's my fault we didn't reach closure on it > > >>>>before > > >>>>TESLA got this far. I was originally pushing this as an > option, but I > > >>>>think I never quite got myself understood. Somewhere in > the mists of > > >>>>time I gave up. I've been taking a back seat on the > TESLA work until > > >>>>just recently, so my brain obviously wasn't in gear > when reviewing > > >>>>drafts. I forgot I'd got this option to attack the DoS > problem. It > > >>>>was > > >>>>only through reveiwing the SRTP draft that the > technique came back to > > >>>>me. Now, the more I argue about it, the better I think it is. > > >>>> > > >>>>However, it's not out of the woods yet. My co-authors > are trying to > > >>>>break it. I believe I've defended it in the case of > variable packet > > >>>>rate and packet misordering. But I'm expecting more > attempts to break > > >>>>it (and, of course, anyone on this list is welcome to > try as well). > > >>>> > > >>>>If it comes out intact, you should see text on it > shortly. Otherwise, > > >>>>I guess the TESLA base spec will stay as it is. > > >>> > > >>>And this sizable email exchange would be in vain :?) > > >>> > > >>>... > > >>>>>>BTW, it should be pointed out that the verification > algo should > > >>>>>>check > > >>>>>>the key index is within an expected range before > using it (e.g. > > >>>>>>only > > >>>>>>a > > >>>>>>small increment above the last highest verified key > index seen). > > >>>>>>Otherwise, an attacker can tamper with this field to lead all > > >>>>>>receivers to run millions of hash operations unnecessarily. I > > >>>>>>prefer > > >>>>>>to call it a key-index *hint*, to remind me not to > rely on it being > > >>>>>>correct. > > >>>>> > > >>>>>This sounds like an argument for keeping the MAC. > > >>>> > > >>>>No. It is an argument for watching that it doesn't > appear to imply > > >>>>packets are extremely re-ordered (e.g. it must be no > more than, say, > > >>>>64 different from the previous highest index, cf the SRTP replay > > >>>>protection window). You /could/ use a group MAC to do > an initial test > > >>>>of its integrity, but why waste 10 octets when you can > do a test that > > >>>>uses none? And this would only work if you trusted the > group members > > >>>>(recall, we are using TESLA because we don't trust them). > > >>> > > >>>The group MAC was originally 4 bytes and I need to check with > > >>>Elisabetta to find out why it is now 10. I don't see > why it needs to > > >>>be larger than 4 bytes for group MAC purposes. If we manage to > > >>>obviate > > >>>the need for group MACs in TESLA, then it can be zero > bytes and I'll > > >>>be > > >>>perfectly happy. > > >>>> > > >>>>The key index is implicitly authenticated (similar to > the implicit > > >>>>header authentication in section 9.5.2 of the SRTP RFC) > because the > > >>>>TESLA MAC depends on it. If the key index is tampered with, the > > >>>>authentication test will fail as it should. > > >>> > > >>>Ok. > > >>>... > > >>>>> > > >>>>>We'll refer to your editorial comments at the next revision. > > >>>> > > >>>>I've added a couple more below... > > >>> > > >>>Good. How do you feel about my proposal to consider the > proposed use > > >>>of the RTP timestamp field separately from the group > MAC. And treat > > >>>the group MAC as a related question to your point 3 scheme? > > >> > > >>Yup. Done. > > >> > > >>Cheers > > >> > > >> > > >>Bob > > >> > > >> > > > >>____________________________________________________________ > ___________ > > _____ > > >>Bob Briscoe, Networks Research > Centre, BT > > >>Research > > >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 > 3RE,UK. +44 1473 > > >>645196 > > >> > > >>_______________________________________________ > > >>msec mailing list > > >>msec@securemulticast.org > > >>http://six.pairlist.net/mailman/listinfo/msec > > > > > > >_____________________________________________________________ > _______________ > > > > >Bob Briscoe, Networks Research > Centre, BT > > Research > > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 > > 645196 > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Sep 15 09:42:35 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03750 for ; Wed, 15 Sep 2004 09:42:34 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D85CF8D614; Wed, 15 Sep 2004 09:42:35 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4C14B8D605 for ; Wed, 15 Sep 2004 09:42:35 -0400 (EDT) Received: (qmail 48685 invoked by uid 3269); 15 Sep 2004 13:42:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48682 invoked from network); 15 Sep 2004 13:42:34 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by klesh.pair.com with SMTP; 15 Sep 2004 13:42:34 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FDgUT15554; Wed, 15 Sep 2004 16:42:31 +0300 (EET DST) X-Scanned: Wed, 15 Sep 2004 16:41:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8FDfBrX026296; Wed, 15 Sep 2004 16:41:11 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00CviPos; Wed, 15 Sep 2004 16:41:08 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FDf5Y27941; Wed, 15 Sep 2004 16:41:06 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Sep 2004 08:41:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Wed, 15 Sep 2004 09:41:01 -0400 Message-ID: Thread-Topic: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Thread-Index: AcSajR/6gJeemdgdQYeXxbyR8swNIgAmtKoQ From: To: , X-OriginalArrivalTime: 15 Sep 2004 13:41:04.0053 (UTC) FILETIME=[A52F6E50:01C49B29] Cc: elisabetta.carrara@ericsson.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable I think in TESLA we are very conservative in terms of whether the packet is authentic. The packet is not authentic anymore if the sender could have already revealed the key, as opposed to the packet is not authentic anymore because the key is revealed and someone could have had time to forge a packet. Given the conservative nature of source authentication of TESLA, there may be some preference in some domains to just have group authentication and no source authentication, to avoid false negatives.=20 In my opinion, we could make group authentication and source = authentication optional, but existence of at least one of them mandatory. I do not know if that is what Bob was refering to. If yes, I would not = mind supporting the option. Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Mark Baugher > Sent: Tuesday, September 14, 2004 2:55 PM > To: Bob Briscoe > Cc: elisabetta.carrara@ericsson.com; msec@securemulticast.org > Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) >=20 >=20 > hi Bob >=20 > On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote: > > > ... > > > > > >> 5/ Discard if a packet cannot be authenticated should be optional > > =3D Agreed >=20 > I did not sign up for this one - or at least I did not mean to. I'd =20 > like to discuss this some more. Personally, I want to limit options =20 > wherever possible and this is the second option (including=20 > making the =20 > group optional) that you have proposed. I don't think we=20 > necessarily =20 > want to add this particular option and would like to hear=20 > what others =20 > have to say on the matter. >=20 > thanks, Mark > > > >> Nits > > =3D To be considered in next draft. > > > > Cheers > > > > > > Bob > > > >> thanks, Mark > >> On Sep 2, 2004, at 1:03 AM, Bob Briscoe wrote: > >> > >>> Mark, > >>> > >>> At 18:49 30/08/2004, Mark Baugher wrote: > >>>> Bob, > >>>> I reply to many of your points below, but here is=20 > something I'd =20 > >>>> like > >>>> for you and your co-authors to consider: Apart from=20 > reusing the RTP > >>>> timestamp field the issue you raise in point 3 is a general TESLA > >>>> issue > >>>> and not an SRTP-TESLA issue. I think this is also true=20 > for guidance > >>>> on > >>>> the use or non-use of a group MAC, which is related to=20 > your point 3. > >>>> I'd like to see these points treated in a general way so why not > >>>> critique the base TESLA spec on this point and not SRTP-TESLA? > >>> > >>> Yup, for the DoS prevention, Ran Canetti has proposed we=20 > need to add =20 > >>> a > >>> more formal DoS mitigation section to TESLA-intro. > >>> > >>> This mail thread just goes to show how getting specific about a > >>> protocol (SRTP) feeds back to the generic description. It was only > >>> when we got to the specifics that the issues became=20 > clear. I'll stop > >>> pestering you for a while on point 3/ (DoS prevention). > >>> > >>> On use/non-use of group MAC, TESLA-intro won't MANDATE=20 > anything. It's > >>> informational. > >>> > >>> More inline. > >>> > >>>> More below... > >>>> On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: > >>>> ... > >>>>> Having thought about it, I will be stronger than the=20 > last mail and > >>>>> say > >>>>> a group MAC will provide barely any additional=20 > protection in most > >>>>> circumstances so should not be the default. The logic of using a > >>>>> group > >>>>> MAC with TESLA looks like this: > >>>>> > >>>>> Sender's level of trust in group members not to=20 > spoof packets > >>>>> | using a group key? | > >>>>> Low High > >>>>> | | > >>>>> Use source authentication (ie TESLA). Use group > >>>>> authentication. > >>>>> | > >>>>> TESLA is vulnerable to DoS filling buffer > >>>>> until delayed auth > >>>>> | > >>>>> Use group authentication alongside TESLA > >>>>> (as in current SRTP draft) > >>>>> > >>>>> I hope this diagram helps highlight the broken logic. > >>>>> Group authentication is being MANDATED in the SRTP draft in a > >>>>> scenario > >>>>> which only ever arises where the group isn't trusted. > >>>> > >>>> Trusted to do or not do what? I think in this case,=20 > "trusted" means > >>>> "trusted not to launch a denial of service attack against the =20 > >>>> group." > >>>> There is also "trusted not to capture a disclosed key to =20 > >>>> successfully > >>>> impersonate a group sender." Further, there is "trusted not to > >>>> disclose a group key" - and so on. Treating something as =20 > >>>> complicated > >>>> as this as "high" or "low" is not persuading me, personally. > >>> > >>> I started out the diag making clear the trust context,=20 > but yes, it =20 > >>> got > >>> munged into unspecified trust in the explanatory para=20 > after. SOrry. I > >>> think it best if I write all the applicability stuff into=20 > a new DoS > >>> sectino in the TESLA-intro, then we can have this debate with some > >>> clarity. > >>> > >>> I hope to do this while the issue is fresh - next few days, but... > >>> > >>> > >>>>> dding group authentication to TESLA only provides any additional > >>>>> value > >>>>> for the narrow range of scenarios where group members aren't =20 > >>>>> trusted > >>>>> enough to use group authentication alone, but they are trusted > >>>>> sufficiently that group authentication might detect some DoS =20 > >>>>> attacks > >>>>> - > >>>>> pretty slim odds. Worth allowing as an option, but surely not > >>>>> MANDATING. > >>>> > >>>> You see a waste of time and bandwidth for protection that is > >>>> superfluous. I see a relatively cheap way to keep a=20 > group protected > >>>> against anyone running a kiddie script who decides to=20 > send a burst =20 > >>>> of > >>>> packets and overflow members' buffers. Let's gather some more =20 > >>>> opinion > >>>> from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, =20 > >>>> BELOW. > >>> > >>> The S/KEY-like scheme in point 3/ is an alternative, but it's now > >>> different to what I described following Adrian Perrig knocking it > >>> down,... me fixing it,... then Adrian agreeing it's now=20 > OK. It's now =20 > >>> a > >>> good option for fixed or nearly-fixed packet rate (eg audio), but > >>> needs applicability carefully explaining for highly=20 > variable packet > >>> rate (eg video). > >>> > >>> I've agreed to document three DoS mitigation=20 > possibilities in a next > >>> TESLA-intro draft: > >>> * check that the disclosed key fits the chain (simple but weak - > >>> always worth doing) > >>> * group MAC > >>> * disclose & use new key each packet > >>> > >>> I think it's best to wait for that before the debate on what > >>> defaults/options/transforms there should be in SRTP-TESLA. > >>> > >>> I've split the remaining reply into separate threads for each =20 > >>> numbered > >>> issue I raised at least those still up for debate, as=20 > requested. THey > >>> are all orthogonal. > >>> > >>> > >>> > >>>>>>> 2/ Non-TESLA group authentication to protect against=20 > DoS should =20 > >>>>>>> be > >>>>>>> optional > >>>>>>>=20 > -----------------------------------------------------------------=20 > >>>>>>> -- -- -- ---- > >>>>>>> The immediate authentication provided by your non-TESLA group > >>>>>>> authentication only protects against DoS by non-group=20 > members. It > >>>>>>> should be RECOMMENDED not REQUIRED (section 7). > >>>>>> > >>>>>> I think that this point should be resolved in the base TESLA > >>>>>> specification, i.e. I don't think there is anything that is > >>>>>> SRTP-specific to this point. But we did not treat it=20 > that way in > >>>>>> SRTP-TESLA, and that's probably my fault. =20 > Nonetheless, I think it > >>>>>> should be REQUIRED in base TESLA. > >>>>> > >>>>> Currently section 5 (security considerations) of the TESLA-intro > >>>>> mentions group authentication as one possible way of preventing > >>>>> flooding attacks during the key disclosure delay. But it doesn't > >>>>> MANDATE it. I'm simply taking issue with group=20 > authentication being > >>>>> MANDATED in SRTP-TESLA, as I don't think it's effective in many > >>>>> (most?) scenarios, making it unnecessary overhead. > >>>>> > >>>>> I have no problem with making a group MAC optional for scenarios > >>>>> where > >>>>> it does improve matters. > >>>> > >>>> I don't have a lot of religious fervor on the topic=20 > either though I > >>>> like to avoid options in security protocols whenever=20 > possible. What > >>>> seemed fairly obvious to me obviously seems wasteful to=20 > you. I'd =20 > >>>> like > >>>> to discuss this further in a separate thread. We are really > >>>> discussing > >>>> a security requirement for protecting groups. > >>>> ... > >>>> > >>>>> > >>>>> Sorry, history was a distracting word. I meant=20 > likelihood. Imagine =20 > >>>>> a > >>>>> video conf between senior execs of competing companies,=20 > or between > >>>>> representatives of mutually distrusting governments.=20 > They don't =20 > >>>>> trust > >>>>> each other not to spoof what the other parties are=20 > saying, but they > >>>>> have no likelihood of one launching a flooding attack=20 > on the other > >>>>> (e.g. the whole thing is over a joint VPN). They need group > >>>>> authentication like a phish needs a bicycle. So why MANDATE it? > >>>> > >>>> We are beating this to death and confusing one another. The > >>>> participants would not launch the flooding attack; an=20 > interloper =20 > >>>> would > >>>> do it. If it's over a VPN, then the attack seems very=20 > unlikely - as > >>>> is > >>>> source spoofing in a small teleconference, for that matter. > >>>> ... > >>>>> > >>>>>> relies upon the fact that memory gets tied up while > >>>>>> packets are buffered awaiting authentication. In this=20 > case, there > >>>>>> is > >>>>>> no buffering of multiple packets, just one packet during the > >>>>>> disclosure > >>>>>> interval. Do I understand you correctly? > >>>>> > >>>>> No. The disclosure *interval* (delay) still spans=20 > multiple packets. > >>>>> The new feature depends on each key now only ever being=20 > *disclosed* > >>>>> once, rather than the same key being disclosed=20 > repeatedly as it was > >>>>> when there were multiple packets in the same TESLA time=20 > interval. > >>>> > >>>> Before we go any further into this, I'd like to=20 > understand why this > >>>> disclosure scheme needs to be considered only for SRTP. =20 > You mention > >>>> below that you also think that it belongs in the base TESLA > >>>> specification and that you have raised the issue with your =20 > >>>> co-authors? > >>>> I think the TESLA co-authors might want to consider=20 > discussing this =20 > >>>> on > >>>> the list. That sounds better than treating SRTP-TESLA=20 > as the poster > >>>> child for something that was maybe overlooked in the base TESLA > >>>> document. > >>>> > >>>> I just got back from some personal time off and am=20 > working through > >>>> several hundred messages - I prioritized yours. It=20 > would be a more > >>>> efficient discussion to discuss this with the TESLA=20 > authors - on the > >>>> msec list if possible. > >>>> > >>>>> > >>>>> As soon as a packet arrives, the disclosed key in it now has two > >>>>> purposes: > >>>>> - it's original TESLA purpose: to verify a packet=20 > received some =20 > >>>>> time > >>>>> previously > >>>>> - to immediately show the receiver that the sender of=20 > this packet > >>>>> knew > >>>>> the next key back along the hash chain which is now only ever > >>>>> *disclosed* once > >>>>> > >>>>> So if more packets are received that *disclose* the=20 > same key, the > >>>>> receiver can assume (at least until the delayed TESLA=20 > verification) > >>>>> that only the first packet to disclose each key was genuine. > >>>>> > >>>>> If a network element is compromised, an attacker can=20 > discover the > >>>>> next > >>>>> disclosed key and overtake or replace a genuine packet with many > >>>>> others. But the receiver can still immediately discard=20 > all but the > >>>>> first to arrive, protecting itself from memory overflow. > >>>>> > >>>>> So the scheme has the following properties: > >>>>> - The receiver will never buffer more than one packet=20 > per packet =20 > >>>>> sent > >>>>> by the genuine sender (so the receiver's buffer fill=20 > rate is still > >>>>> clocked by the party that reveals each new key backwards in the > >>>>> chain). > >>>>> - As each key is later disclosed, TESLA can do delayed=20 > verification > >>>>> of > >>>>> these stored packets. > >>>>> - if they pass delayed verfication, the messages must=20 > be genuine > >>>>> - if they fail delayed verfication, the messages must=20 > not have =20 > >>>>> been > >>>>> genuine > >>>>> - The true message will have been lost in the latter=20 > case. But, =20 > >>>>> then > >>>>> if an attacker can compromise a network element, it can=20 > discard the > >>>>> true messages anyway (a group MAC can't prevent this either ;) > >>>>> > >>>>> I need to fully document this. There are some corner cases not > >>>>> covered > >>>>> by the above. I've given an outline later. Obviously, this DoS > >>>>> protection idea hasn't had the same peer-review as=20 > TESLA, except it > >>>>> is > >>>>> essentially just S/KEY, which has had ample peer review (but =20 > >>>>> perhaps > >>>>> not in a group setting). > >>>> > >>>> This sounds promising to me, but I would like to see the=20 > document - =20 > >>>> I > >>>> have not read the one you sent me yet. And I would like=20 > to hear =20 > >>>> what > >>>> the other TESLA authors have to say about it. > >>>> > >>>> ... > >>>>>> If so, why > >>>>>> not put this in the core TESLA specification. I'd say=20 > that if it > >>>>>> belongs in SRTP-TESLA, then it belongs in the core=20 > specification. > >>>>>> No? > >>>>> > >>>>> You are absolutely correct. > >>>>> > >>>>> We (the co-authors of the TESLA base spec) are discussing this > >>>>> off-line right now. It's my fault we didn't reach closure on it > >>>>> before > >>>>> TESLA got this far. I was originally pushing this as an=20 > option, =20 > >>>>> but I > >>>>> think I never quite got myself understood. Somewhere in=20 > the mists =20 > >>>>> of > >>>>> time I gave up. I've been taking a back seat on the TESLA work =20 > >>>>> until > >>>>> just recently, so my brain obviously wasn't in gear=20 > when reviewing > >>>>> drafts. I forgot I'd got this option to attack the DoS=20 > problem. It > >>>>> was > >>>>> only through reveiwing the SRTP draft that the=20 > technique came back =20 > >>>>> to > >>>>> me. Now, the more I argue about it, the better I think it is. > >>>>> > >>>>> However, it's not out of the woods yet. My co-authors=20 > are trying to > >>>>> break it. I believe I've defended it in the case of=20 > variable packet > >>>>> rate and packet misordering. But I'm expecting more=20 > attempts to =20 > >>>>> break > >>>>> it (and, of course, anyone on this list is welcome to=20 > try as well). > >>>>> > >>>>> If it comes out intact, you should see text on it shortly. =20 > >>>>> Otherwise, > >>>>> I guess the TESLA base spec will stay as it is. > >>>> > >>>> And this sizable email exchange would be in vain :?) > >>>> > >>>> ... > >>>>>>> BTW, it should be pointed out that the verification=20 > algo should > >>>>>>> check > >>>>>>> the key index is within an expected range before=20 > using it (e.g. > >>>>>>> only > >>>>>>> a > >>>>>>> small increment above the last highest verified key=20 > index seen). > >>>>>>> Otherwise, an attacker can tamper with this field to lead all > >>>>>>> receivers to run millions of hash operations unnecessarily. I > >>>>>>> prefer > >>>>>>> to call it a key-index *hint*, to remind me not to=20 > rely on it =20 > >>>>>>> being > >>>>>>> correct. > >>>>>> > >>>>>> This sounds like an argument for keeping the MAC. > >>>>> > >>>>> No. It is an argument for watching that it doesn't=20 > appear to imply > >>>>> packets are extremely re-ordered (e.g. it must be no=20 > more than, =20 > >>>>> say, > >>>>> 64 different from the previous highest index, cf the SRTP replay > >>>>> protection window). You /could/ use a group MAC to do=20 > an initial =20 > >>>>> test > >>>>> of its integrity, but why waste 10 octets when you can=20 > do a test =20 > >>>>> that > >>>>> uses none? And this would only work if you trusted the group =20 > >>>>> members > >>>>> (recall, we are using TESLA because we don't trust them). > >>>> > >>>> The group MAC was originally 4 bytes and I need to check with > >>>> Elisabetta to find out why it is now 10. I don't see=20 > why it needs =20 > >>>> to > >>>> be larger than 4 bytes for group MAC purposes. If we manage to > >>>> obviate > >>>> the need for group MACs in TESLA, then it can be zero=20 > bytes and I'll > >>>> be > >>>> perfectly happy. > >>>>> > >>>>> The key index is implicitly authenticated (similar to=20 > the implicit > >>>>> header authentication in section 9.5.2 of the SRTP RFC)=20 > because the > >>>>> TESLA MAC depends on it. If the key index is tampered with, the > >>>>> authentication test will fail as it should. > >>>> > >>>> Ok. > >>>> ... > >>>>>> > >>>>>> We'll refer to your editorial comments at the next revision. > >>>>> > >>>>> I've added a couple more below... > >>>> > >>>> Good. How do you feel about my proposal to consider the=20 > proposed =20 > >>>> use > >>>> of the RTP timestamp field separately from the group=20 > MAC. And treat > >>>> the group MAC as a related question to your point 3 scheme? > >>> > >>> Yup. Done. > >>> > >>> Cheers > >>> > >>> > >>> Bob > >>> > >>> > >>>=20 > _____________________________________________________________________=20 > >>> __ _____ > >>> Bob Briscoe, Networks Research=20 > Centre, BT > >>> Research > >>> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5=20 > 3RE,UK. +44 1473 > >>> 645196 > >>> > >>> _______________________________________________ > >>> msec mailing list > >>> msec@securemulticast.org > >>> http://six.pairlist.net/mailman/listinfo/msec > >> > >>=20 > ______________________________________________________________ > ________=20 > >> ______ > >> Bob Briscoe, Networks Research=20 > Centre, BT =20 > >> Research > >> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.=20 > +44 1473 =20 > >> 645196 > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Sep 15 12:12:39 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16138 for ; Wed, 15 Sep 2004 12:12:38 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 441F78CC5E; Wed, 15 Sep 2004 12:12:39 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 63E538C77D for ; Wed, 15 Sep 2004 12:12:38 -0400 (EDT) Received: (qmail 81485 invoked by uid 3269); 15 Sep 2004 16:12:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81482 invoked from network); 15 Sep 2004 16:12:38 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 15 Sep 2004 16:12:38 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2004 09:20:51 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8FG8cpH020536; Wed, 15 Sep 2004 09:09:57 -0700 (PDT) Received: from [128.107.163.74] (dhcp-128-107-163-74.cisco.com [128.107.163.74]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXD31885; Wed, 15 Sep 2004 09:07:31 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20040914183456.01b2d310@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040914172405.028d5eb0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040914183456.01b2d310@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8382CF12-0731-11D9-B3B2-0003935495EC@cisco.com> Content-Transfer-Encoding: 7bit From: "David A. McGrew" Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Wed, 15 Sep 2004 09:08:42 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: "Elisabetta Carrara (KI/EAB)" , Mark Baugher , "'msec@securemulticast.org'" X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Bob, On Sep 14, 2004, at 11:24 AM, Bob Briscoe wrote: > David, Mark, > > At 18:06 14/09/2004, David A. McGrew wrote: >> In my experience with SRTP, it is best to make as few assumptions >> about >> the RTP fields as possible. It would be better for SRTP TESLA to not >> re-use the RTP timestamp, in my opinion, because that will better >> enable the protocol to be used with existing RTP systems without any >> security concern. I regret the loss of four bytes packet for a >> TESLA-specific timestamp, but I would prefer to have a protocol that >> we >> could recommend without qualifications. > > Tx for both your explanations, which make it all much clearer why it's > more complicated. I've scanned the refs you gave and now I know how > much I don't know. Although you all seem to know a fair bit about this > and have a good deal of experience, may I be so bold as to say that I > detect there is an element of assuming there might be a problem, > rather than strictly analysing whether there really is a problem. No, that is not the case. I favor making the security of SRTP TESLA independent of the use of the RTP timestamp so that protocol will be resilient against different usages of RTP. Here is an example of a use of RTP that will break when used with your proposal. Define the 'short message' codec as one that passes short ASCII strings in the RTP payload, with a timestamp that starts at zero and is monotonically increasing. The receiver is expected to display these messages in order, e.g. on a display panel. Now interleave the use of this code with an audio codec over the same SSRC, using the Payload Type field in the RTP header to indicate which codec is in effect for each packet. (Example application: pass URLs or phone numbers during a presentation.) The timestamp is set by the codec, and every time that the payload type switches to the 'short message' codec, the timestamp jumps to zero again. It can be debated whether or not the RTP usage that I described is legal w.r.t. the specifications, since the SSRC did not change when the codec changed (which is the preferred behavior). However, this sort of RTP usage *does* occur in practice, so its conformance with the specifications is a moot point. David > This is relevant to whether we make a key index field MANDATORY or > OPTIONAL. I'm just wary of adding bloat to a protocol because no-one > can work out (without a lot of work) whether it is needed or not. > > If the key index were derived from the RTP timestamp: > > i) TESLA security would depend absolutely on the RTP timestamp not > stating a time AFTER the packet had been sent. > I can't see a case where this might happen. Is there? > > ii) Also TESLA performance would depend on the RTP timestamp not > stating a time too far (x) prior to sending (eg when a video frame is > split into multiple packets). > If (network_delay + x) still allowed a workable authentication delay, > there might not be a performance problem. > > It seems that the various timestamp bases can all be recalculated back > to wallclock time. So changing codecs, etc should all be OK. But, I > have a great deal of uncertainty over that statement. > > At first sight, PSTN gateways seem a problem: converting DTMF tones in > the audio to a new stream of telephony event media packets. Clearly, > these would be timestamped after they left the original sender. But, > of course, being new payloads, these would have to be authenticated by > the gateway, not the sender. Requiring each TESLA receiver to time > synch with the gateway as another source. Arrrgghh - the complications > of legacy... ...but importantly these are complications, not protocol > failures. > > Do you get my drift? THe real question is: > - MANDATORY key index because we're sure dependence on the RTP > timestamp will cause security or performance failures in ALL cases (or > such a large majory of cases that having an option would cause > unnecessary complication) > - OPTIONAL key index, because we think it might cause problems, but > no-one can be bothered to work it all out to see whether there will be > a significant number of cases that CAN safely rely on the RTP > timestamp. > > > > Bob > > > _______________________________________________________________________ > _____ > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 16 03:23:33 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18197 for ; Thu, 16 Sep 2004 03:23:33 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 667328D57E; Thu, 16 Sep 2004 03:23:34 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 86C898C010 for ; Thu, 16 Sep 2004 03:23:32 -0400 (EDT) Received: (qmail 80852 invoked by uid 3269); 16 Sep 2004 07:23:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80834 invoked from network); 16 Sep 2004 07:23:28 -0000 Received: from smail3.alcatel.fr (194.133.58.56) by klesh.pair.com with SMTP; 16 Sep 2004 07:23:28 -0000 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i8G7NPVD000986 for ; Thu, 16 Sep 2004 09:23:25 +0200 Importance: Low To: msec@securemulticast.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Laurence.Duquerroy@space.alcatel.fr Date: Thu, 16 Sep 2004 09:23:20 +0200 X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 16/09/2004 09:23:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Cc: Sebastien.Josset@space.alcatel.fr Subject: [MSEC] new Internet draft : use case of GDOI X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hello all, You will find below the announcement for the new version of an internet draft whose last version was presented to the group last year, at the Vienna meeting, in July 2003 (sorry for the long delay!) . The protocol described in this draft is entitled "Flat Multicast Key Exchange". It is destined to be a use case of GDOI adapted for satellite networks. It is defined to be low ressource consuming in bandwidth, to be used in any satellite networks topologies and to implement a reliable key distribution Taking into account the comments we received , the draft has been updated in order to present FMKE as a use case of GDOI and to underline the differences between both protocols (for the time being , we have not changed the name of the protocol, but it could be relevant to do so). The draft has been submitted to the IETF secretariat as an individual draft related to no group. We hope that you will find interest in it, and that it can be officially submitted as a MSEC draft afterwards. We thank you in advance for your comments and questions. Best regards, Laurence Duquerroy Sebastien Josset ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Flat Multicast Key Exchange protocol Author(s) : L. Duquerroy, S. Josset Filename : draft-duquer-fmke-01.txt Pages : 38 Date : 2004-9-15 This document presents a new group key management protocol called FMKE (Flat Multicast Key Exchange), derived from the Group Domain of Interpretation (GDOI) [RFC3547]. Like the GDOI, its objective is to Manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. This protocol is based on a centralized management, achieved by the GCKS (Group Controller and Key Server). It is destined to be used by Data Security protocols such as the IPSEC ESP protocol. The FMKE protocol is destined to provide an optimized solution for very large groups with direct connections such as in satellite systems, or wireless systems such as WIFI. It can be considered as a GDOI use case adapted for satellite networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duquer-fmke-01.txt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 16 05:42:15 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26314 for ; Thu, 16 Sep 2004 05:42:14 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 004DE8D0B8; Thu, 16 Sep 2004 05:42:15 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5540B8CFAA for ; Thu, 16 Sep 2004 05:42:13 -0400 (EDT) Received: (qmail 13981 invoked by uid 3269); 16 Sep 2004 09:42:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 13978 invoked from network); 16 Sep 2004 09:42:12 -0000 Received: from tama5.ecl.ntt.co.jp (129.60.39.102) by klesh.pair.com with SMTP; 16 Sep 2004 09:42:12 -0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9fvRH012076; Thu, 16 Sep 2004 18:42:00 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9fvgi027334; Thu, 16 Sep 2004 18:41:57 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9fvN2027331; Thu, 16 Sep 2004 18:41:57 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9fu7o000593; Thu, 16 Sep 2004 18:41:56 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9fuDs000590; Thu, 16 Sep 2004 18:41:56 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9ftlO008945; Thu, 16 Sep 2004 18:41:56 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9ftmo013452; Thu, 16 Sep 2004 18:41:55 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (ipf0.m.ecl.ntt.co.jp [129.60.5.159]) by eclscan2.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8G9fto1013444; Thu, 16 Sep 2004 18:41:55 +0900 (JST) Received: from hiroshi-tp3.lab.ntt.co.jp by imf.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA04254; Thu, 16 Sep 2004 18:41:54 +0900 (JST) Message-Id: <6.1.0.6.2.20040916184111.03424ed8@imf.m.ecl.ntt.co.jp> X-Sender: ho016@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Jr4 Date: Thu, 16 Sep 2004 18:41:20 +0900 To: msec@securemulticast.org From: Hiroshi Ohta Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: haixiang@nortelnetworks.com, satou.hiroaki@lab.ntt.co.jp, hayashi.tsunemasa@lab.ntt.co.jp Subject: [MSEC] BoF: New draft and ML for well managed IP multicasting issues X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi, I would like to inform you that we are preparing a new BoF. I encourage you to join the discussion. We prepared an I-D on requirements to well managed IP multicasting services and set up a mailing list to discuss this issue. It is essential for IP multicasting function to have accounting capabilities so that network operator can grasp user activities (i.e., Join/Leave) when one wants to provide services which include payments (e.g., between user and a service provider, between a content provider and a network operator, etc.). Another case we need accounting function for multicasting is where one want to grasp who received what information (and when) such as distance learning. Unfortunately, there is no appropriate WG to discuss this issue. We got a suggestion from ADs to try a BoF because it is an important problem although no WG fits now. The draft is: The mailing list is: Have a look and join the mailing list if you are interested. To join the mailing list, just send a blank mail to and reply to the confirmation mail you will receive. Please note that the confirmation message indicates to reply to a different address from the one the 'reply' command generates. Please do not worry and just reply using 'reply' command. Our intention toward the next IETF meeting (IETF-61) in Washington D.C. is to have a BoF session on this issue. Within the BoF (and hopefully within the subsequent WG), we will discuss and clarify the requirements first, and then discuss and find out a good solution for it. I would appreciate your feedbacks. Best regards, Hiroshi ---------------------------------------- Hiroshi OHTA NTT Network Service Systems Laboratories Tel: +81 422 59 3617 Fax: +81 422 37 8519 E-mail: ohta.hiroshi@lab.ntt.co.jp _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 17 12:54:09 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19727 for ; Fri, 17 Sep 2004 12:54:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5D91A8D811; Fri, 17 Sep 2004 12:54:10 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DB7A38D80E for ; Fri, 17 Sep 2004 12:54:08 -0400 (EDT) Received: (qmail 80868 invoked by uid 3269); 17 Sep 2004 16:54:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80865 invoked from network); 17 Sep 2004 16:54:08 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 17 Sep 2004 16:54:08 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 Sep 2004 09:54:16 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn5-1201.cisco.com [10.21.92.177]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8HGs33c025745; Fri, 17 Sep 2004 09:54:04 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28A0FFFA-08CA-11D9-9A2E-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] new Internet draft : use case of GDOI Date: Fri, 17 Sep 2004 09:53:54 -0700 To: Laurence.Duquerroy@space.alcatel.fr X-Mailer: Apple Mail (2.619) Cc: Sebastien.Josset@space.alcatel.fr, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit hi Laurence, Sebastien, I have a few questions and comments. 1. The first figure shows two cases but there are three: star-bidirectional, star-unidirectional, and mesh. Do I understand this correctly? (It would be helpful to label the figure). 2. I don't understand a sentence on page 5: "Unlike GDOI, this phase takes place once, after the Phase 1." The phase 2, which I think you're describing always takes place after phase 1. After reading this paragraph a few times, it seems that you are defining a new phase 2 pull exchange that allows more than one group to be specified in an ID payload so that all groups can be downloaded in one exchange (not necessarily in one message because of MTU and fragmentation issues). Do I understand this correctly? 3. Also on page 5, the innovation introduced to GDOI is to add a reliability mechanism to the groupkey-push message is it not? 4. On page 6 you discuss the phase 1 but not how the phase 1 is established in the star-unidirectional case. Is this an oversight? A forward reference to 6.1 would help here. 5. On page 6, the phase 2 is initiated by the GCKS. What causes the GCKS to initiate this message? I assume that the first GCKS message is sent exactly twice? 6. How are groups identified in the new phase 2? I don't see the ID payload. 7. On page 7, the SEQ is redefined to apply to the groupkey-pull and not the groupkey-push, if I understand this correctly. I think it would be better not to reuse the name for such a different purpose, which I don't yet understand. Don't we need a SEQ for the original purpose of ordering pushed messages? 8. On page 10, it appears that the SEQ is used in the phase 3 so I'm confused. I also don't immediately grasp why the LSEQ is needed since the SEQ performs an LSEQ function, or so it seems. 9. On page 10 there is also a push message that originates from the member. GDOI reuses the phase 2 for this purpose or a similar purpose. Why not use the GDOI phase 2? 10. On page 13, section 6.1 should be referenced earlier when the star-unidirectional topology is described. 11. I'm not sure why the manual configuration of phase 1 SAs cannot obviate the need to modify the phase 2 into a push. In the original GDOI design, I thought that the groupkey-push, what you call the phase 3, would be all that is needed for one-way systems. 12. On page 14, it seems odd to have to modify a pushed message because there is no backchannel, since the objective of the push message is to operate without a backchannel. I'm not sure what role the LSEQ plays when there is no backchannel: Why not just send the complete message, let the SEQ perform the function of the LSEQ, and send the needed payloads in the message? 13. Page 15 states that the SEQ is used but does not mention that it was redefined as stated earlier in the document. Also, the list of GDOI payloads used is incomplete, isn't it? What happened to POP? At this point, I am skipping the details of the payloads to ask a question: Would it be possible to modify GDOI as it is without developing a new DOI? I'm sure that there are features missing in GDOI for broadcast and for unidirectional networks. We talked a lot about adding reliability mechanisms into GDOI and that's a big topic. There are a number of different reliable multicast algorithms to choose from and a "chicken and egg problem" since GDOI is needed to establish keys to protect reliable multicast systems. Speaking strictly for myself, I wanted to defer the issue until we had a real system with real experts to help. And here you are. My first choice would be to try to minimize the fmke changes and fold them into GDOI, publish a new version of GDOI, and cycle on Proposed Standard. The advantage to doing this is that fmke can then benefit more directly to bug fixes (such as the POP problem that Catherine and her co-author identified), new features (possibly such as sibling SAs), and general improvements. If fmke is incorporated into GDOI, then these things don't need to be done twice. It might be the case that it's too complicated to try and handle two different scenaria in a single protocol, and we'll want to separate them. But 2/3 of your topologies are topologies that GDOI is supposed to handle but needs added functionality for reliable multicast. I personally expected that we would need to introduce changes for this. Mark On Sep 16, 2004, at 12:23 AM, Laurence.Duquerroy@space.alcatel.fr wrote: > Hello all, > > You will find below the announcement for the new version of an > internet > draft whose last version was > presented to the group last year, at the Vienna meeting, in July 2003 > (sorry for the long delay!) . > > The protocol described in this draft is entitled "Flat Multicast Key > Exchange". It is destined to be a use case of GDOI adapted for > satellite > networks. > It is defined to be low ressource consuming in bandwidth, to be used > in any > satellite networks topologies and to implement a reliable key > distribution > > Taking into account the comments we received , the draft has been > updated > in order to present FMKE as a use case of GDOI and to underline the > differences between both protocols (for the time being , we have not > changed the name of the protocol, but it could be relevant to do so). > > The draft has been submitted to the IETF secretariat as an individual > draft > related to no group. We hope that you will find interest in it, and > that it > can be officially submitted as a MSEC draft afterwards. We thank you > in > advance for your comments and questions. > > Best regards, > > Laurence Duquerroy > Sebastien Josset > > ALCATEL SPACE > RT/ST > Research Department / Advanced Telecom Satellite Systems > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > E-Mail : laurence.duquerroy@space.alcatel.fr > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The Flat Multicast Key Exchange protocol > Author(s) : L. Duquerroy, S. Josset > Filename : draft-duquer-fmke-01.txt > Pages : 38 > Date : 2004-9-15 > > This document presents a new group key management protocol called > FMKE (Flat Multicast Key Exchange), derived from the Group Domain of > Interpretation (GDOI) [RFC3547]. Like the GDOI, its objective is to > Manage securely group Security Associations (SA), i.e. establish and > update SAs in Group members. These security associations protect one > or more key-encrypting keys, traffic-encrypting keys, or data shared > by group members. This protocol is based on a centralized > management, > achieved by the GCKS (Group Controller and Key Server). It is > destined to be used by Data Security protocols such as the IPSEC ESP > protocol. The FMKE protocol is destined to provide an optimized > solution for very large groups with direct connections such as in > satellite systems, or wireless systems such as WIFI. It can be > considered as a GDOI use case adapted for satellite networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-duquer-fmke-01.txt > > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Sep 22 12:34:09 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21749 for ; Wed, 22 Sep 2004 12:34:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C5B1F8D474; Wed, 22 Sep 2004 12:34:05 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0C55F8D55D for ; Wed, 22 Sep 2004 12:34:04 -0400 (EDT) Received: (qmail 56920 invoked by uid 3269); 22 Sep 2004 16:34:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56917 invoked from network); 22 Sep 2004 16:34:03 -0000 Received: from smail3.alcatel.fr (62.23.212.56) by klesh.pair.com with SMTP; 22 Sep 2004 16:34:03 -0000 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.182.220]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i8MGVlLl008327; Wed, 22 Sep 2004 18:31:47 +0200 Importance: Low Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_[MSEC]_new_Internet_draft_=3A_use_case?= of GDOI To: mbaugher@cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Laurence.Duquerroy@space.alcatel.fr Date: Wed, 22 Sep 2004 18:31:44 +0200 X-MIMETrack: Serialize by Router on VZMTA01/ALCANET/ALCATEL-SPACE(Release 5.0.12 |February 13, 2003) at 22/09/2004 18:31:47 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes Cc: Sebastien.Josset@space.alcatel.fr, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hi Mark. Thanks for all your comments and questions. Please find below our responses. Laurence Mark Baugher on 17/09/2004 18:53:54 Pour : Laurence Duquerroy/ALCATEL-SPACE@ALCATEL-SPACE cc : msec@securemulticast.org Sebastien Josset/ALCATEL-SPACE@ALCATEL-SPACE Objet : Re: [MSEC] new Internet draft : use case of GDOI >hi Laurence, Sebastien, > I have a few questions and comments. >1. The first figure shows two cases but there are three: >star-bidirectional, star-unidirectional, and mesh. Do I understand >this correctly? (It would be helpful to label the figure). 1.Yes, there are 3 cases : star topology with bi-directional communicat= ions between ST and gateway, star topology with unidirectional communication= s from gateway to ST, and mesh topology with bi-directional communication= s between STs. >2. I don't understand a sentence on page 5: "Unlike GDOI, this phase >takes place once, after the Phase 1." The phase 2, which I think >you're describing always takes place after phase 1. After reading thi= s >paragraph a few times, it seems that you are defining a new phase 2 >pull exchange that allows more than one group to be specified in an ID= >payload so that all groups can be downloaded in one exchange (not >necessarily in one message because of MTU and fragmentation issues). >Do I understand this correctly? 2. In GDOI, the "Group key pull" exchange takes place several times, in= fact every time that the group member wants to get access to a new grou= p. In FMKE, the "philosophy" is different. The group member does not have = to request to get access to a group. It receives directly from the GCKS th= e SAs of all groups it belongs to. So we think only one phase 2 per group= member is necessary. This phase is used to transmit to it all SAs it is= authorized to receive (belonging to different groups or not). Besides, in FMKE, the ID payload is not used. In GDOI, it is used by th= e group member to request SAs from a particular group. I think that's the= only utilization (but I could be wrong). So, since in FMKE, the group member does not request SAs, we have the feeling that it is not necessa= ry to use this payload. The group member does not need to know that a SA belongs to one group or another one. >3. Also on page 5, the innovation introduced to GDOI is to add a >reliability mechanism to the groupkey-push message is it not? 3.Yes, it is. That's the only difference for the groupkey-push >4. On page 6 you discuss the phase 1 but not how the phase 1 is >established in the star-unidirectional case. Is this an oversight? A= >forward reference to 6.1 would help here. 4.OK (it is an oversight) >5. On page 6, the phase 2 is initiated by the GCKS. What causes the >GCKS to initiate this message? I assume that the first GCKS message i= s >sent exactly twice? 5.After much thought, it seems quite difficult to trigger the phase 2 i= n the GCKS as it cannot know if the phase 1 is complete or not. So, the draft needs to be updated. The solution which can be proposed is to add a message from the group member at the begining of the phase 2. This message would trigger the phase 2 (like in the GDOI groupkey pull exchange). We could maybe use = the same message as in GDOI group key pull (with an ID payload set to 0, i= n order not to request the access to a particular group). This solution w= ould be destined only to bidirectionnal communication cases. In the case of one-way systems, this message would not be used. The pha= se 2 would be used as it is described in the current draft, and would be triggered in the GCKS by a security operator for example. >6. How are groups identified in the new phase 2? I don't see the ID >payload. 6. See question 2). In the case of FMKE, it seems that groups need only= to be identified in the GCKS, in order that it can identify the group memb= ers and the SAs of each group. >7. On page 7, the SEQ is redefined to apply to the groupkey-pull and >not the groupkey-push, if I understand this correctly. I think it >would be better not to reuse the name for such a different purpose, >which I don't yet understand. Don't we need a SEQ for the original >purpose of ordering pushed messages? 7.In FMKE, the SEQ payload is used to order GCKS messages: - In a phase 2 , it orders GCKS phase 2 messages (its= function is different from the function of the SEQ payload in GDOI grou= pkey pull) - In a phase 3 , it orders GCKS phase 3 messages (sam= e function as in GDOI). In GDOI groupkey pull, the SEQ payload is used to mention the sequence number value of the next groupkey push message sent by the GCKS for the= group identified by the ID payload. In FMKE, a phase 2 message can contain several Rekey SA, each one associated to a different group. So it is not possible to mention the n= ext sequence number value for each group in a payload. This value is mentio= ned in the SAK payload as a SA attribute (called Next-sequence-number). >8. On page 10, it appears that the SEQ is used in the phase 3 so I'm >confused. I also don't immediately grasp why the LSEQ is needed since= >the SEQ performs an LSEQ function, or so it seems. 8. The function of the LSEQ payload is to periodically mention the valu= e of the last sequence number used by the GCKS to order messages containing = SAs. The LSEQ (Last Sequence Number) payload allows group members to detect = for instance that they have not received the last message, and then to requ= est its retransmission. Example : Next sequence number used by the GCKS =3D 5 Messages sent by the GCKS : 5 6 7 8 9 Messages received by a member : 5 6 7 . . Periodic message with LSEQ value =3D 9 Non-acknowledgement sent by the member : Nack 8-9 (= this non-acknowledgement message triggers the retransmission of messag= es 8 and 9) >9. On page 10 there is also a push message that originates from the >member. GDOI reuses the phase 2 for this purpose or a similar purpose= . > Why not use the GDOI phase 2? 9.I am not sure of understanding the question >10. On page 13, section 6.1 should be referenced earlier when the >star-unidirectional topology is described. 10. OK >11. I'm not sure why the manual configuration of phase 1 SAs cannot >obviate the need to modify the phase 2 into a push. In the original >GDOI design, I thought that the groupkey-push, what you call the phase= >3, would be all that is needed for one-way systems. 11.For one-way systems, using only the group-key push (or phase 3 ) to configure members is indeed possible. This solution requires to configu= re manually every group member with the Re-key SAs of the groups it belong= to. This solution is interesting. However, if new groups are created during= the session, this requires to update manually each corresponding group memb= ers. This cannot be realised dynamically.In satellite systems, STs are dista= nt from each other and from the gateway, so this is not very easy to reali= ze. The second solution (i.e. to use both FMKE phase 2 and phase 3 ) seems= better in this case. Only an initial configuration is necessary. Then a= ny further configurations can be realized dynamically.Maybe should we keep= both solutions. Moreover there is another argument for the second solution, but it is o= ut of the scope of the MSEC group. In fact, it is planed to use FMKE to ma= nage group SA but also point-to-point SA. Point-to-point SA and Group SA wou= ld be distributed by the GCKS at the same time by using the phase 2 exchan= ge. That's why we need also to keep the phase 2 in one-way systems. >12. On page 14, it seems odd to have to modify a pushed message becaus= e >there is no backchannel, since the objective of the push message is to= >operate without a backchannel. I'm not sure what role the LSEQ plays >when there is no backchannel: Why not just send the complete message,= >let the SEQ perform the function of the LSEQ, and send the needed >payloads in the message? 12. In fact there is a mistake, the messages containing the LSEQ payloa= d (allowing group members to determine missing messages) are not necessar= y in one-way systems, as group members cannot send non-acknowledgement messages.Besides, push messages sent by the GCKS are not modified for one-way systems. >13. Page 15 states that the SEQ is used but does not mention that it >was redefined as stated earlier in the document. Also, the list of >GDOI payloads used is incomplete, isn't it? What happened to POP? 13. We have chosen to use the SEQ payload in phase 2 to order the GCK= S messages, because in GDOI, this payload has a similar function in the G= roup key push exchange. Maybe it is not the better solution. For the POP payload, we have considered that it is similar to GDOI, and= so we have not taken the time to describe it in the draft. >At this point, I am skipping the details of the payloads to ask a >question: Would it be possible to modify GDOI as it is without >developing a new DOI? I'm sure that there are features missing in GDO= I >for broadcast and for unidirectional networks. We talked a lot about >adding reliability mechanisms into GDOI and that's a big topic. There= >are a number of different reliable multicast algorithms to choose from= >and a "chicken and egg problem" since GDOI is needed to establish keys= >to protect reliable multicast systems. Speaking strictly for myself, = I >wanted to defer the issue until we had a real system with real experts= >to help. And here you are. >My first choice would be to try to minimize the fmke changes and fold >them into GDOI, publish a new version of GDOI, and cycle on Proposed >Standard. The advantage to doing this is that fmke can then benefit >more directly to bug fixes (such as the POP problem that Catherine and= >her co-author identified), new features (possibly such as sibling SAs)= , >and general improvements. If fmke is incorporated into GDOI, then >these things don't need to be done twice. >It might be the case that it's too complicated to try and handle two >different scenaria in a single protocol, and we'll want to separate >them. But 2/3 of your topologies are topologies that GDOI is supposed= >to handle but needs added functionality for reliable multicast. I >personally expected that we would need to introduce changes for this. >Mark Modifying GDOI in order to fold into it FMKE changes and add supplement= ary features could be an interesting option. It is difficult to say now if = it is possible, but we would be very interested to participate to this analysis . On Sep 16, 2004, at 12:23 AM, Laurence.Duquerroy@space.alcatel.fr wrote= : > Hello all, > > You will find below the announcement for the new version of an > internet > draft whose last version was > presented to the group last year, at the Vienna meeting, in July 200= 3 > (sorry for the long delay!) . > > The protocol described in this draft is entitled "Flat Multicast Key > Exchange". It is destined to be a use case of GDOI adapted for > satellite > networks. > It is defined to be low ressource consuming in bandwidth, to be used > in any > satellite networks topologies and to implement a reliable key > distribution > > Taking into account the comments we received , the draft has been > updated > in order to present FMKE as a use case of GDOI and to underline the > differences between both protocols (for the time being , we have not > changed the name of the protocol, but it could be relevant to do so).= > > The draft has been submitted to the IETF secretariat as an individual= > draft > related to no group. We hope that you will find interest in it, and > that it > can be officially submitted as a MSEC draft afterwards. We thank yo= u > in > advance for your comments and questions. > > Best regards, > > Laurence Duquerroy > Sebastien Josset > > ALCATEL SPACE > RT/ST > Research Department / Advanced Telecom Satellite Systems > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > E-Mail : laurence.duquerroy@space.alcatel.fr > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - > - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The Flat Multicast Key Exchange protocol > Author(s) : L. Duquerroy, S. Josset > Filename : draft-duquer-fmke-01.txt > Pages : 38 > Date : 2004-9-15 > > This document presents a new group key management protocol called > FMKE (Flat Multicast Key Exchange), derived from the Group Domain = of > Interpretation (GDOI) [RFC3547]. Like the GDOI, its objective is t= o > Manage securely group Security Associations (SA), i.e. establish a= nd > update SAs in Group members. These security associations protect o= ne > or more key-encrypting keys, traffic-encrypting keys, or data shar= ed > by group members. This protocol is based on a centralized > management, > achieved by the GCKS (Group Controller and Key Server). It is > destined to be used by Data Security protocols such as the IPSEC E= SP > protocol. The FMKE protocol is destined to provide an optimized > solution for very large groups with direct connections such as in > satellite systems, or wireless systems such as WIFI. It can be > considered as a GDOI use case adapted for satellite networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-duquer-fmke-01.txt > > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr = _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec