From mailman-bounces@six.pairlist.net Wed Dec 1 05:03:49 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 FAA09044 for ; Wed, 1 Dec 2004 05:03:49 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2754D8DAA0 for ; Wed, 1 Dec 2004 05:03:47 -0500 (EST) 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 Dec 2004 05:01:25 -0500 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 Dec 1 11:52:13 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 LAA25738 for ; Wed, 1 Dec 2004 11:52:12 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A88248D942; Wed, 1 Dec 2004 11:52:13 -0500 (EST) 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 515708CB15 for ; Wed, 1 Dec 2004 11:52:12 -0500 (EST) Received: (qmail 67244 invoked by uid 3269); 1 Dec 2004 16:52:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67241 invoked from network); 1 Dec 2004 16:52:11 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by klesh.pair.com with SMTP; 1 Dec 2004 16:52:11 -0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB1Gppv19762; Wed, 1 Dec 2004 18:52:03 +0200 (EET) X-Scanned: Wed, 1 Dec 2004 18:45:58 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iB1GjwaJ022205; Wed, 1 Dec 2004 18:45:58 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00E9x1e0; Wed, 01 Dec 2004 18:45:56 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iB1GjtS15713; Wed, 1 Dec 2004 18:45:55 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 1 Dec 2004 10:45:54 -0600 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] RE: MUST/MAY discard unverifiable(draft-ietf-msec-srtp-tesla-02.txt) Date: Wed, 1 Dec 2004 11:45:52 -0500 Message-ID: Thread-Topic: MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla-02.txt) Thread-Index: AcTVngaeJGZzUBp/R8emHYY6v+F19QAhNjUgAGgMtAA= From: To: , , X-OriginalArrivalTime: 01 Dec 2004 16:45:54.0622 (UTC) FILETIME=[397CB5E0:01C4D7C5] Cc: ldondeti@nortelnetworks.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 IMO, generally if neither source authentication nor group=20 authentication succeeds, we MUST discard the packet. A MAY=20 for failure of source authentication can be accepted in=20 certain situations provided there is a group authentication=20 success.=20 TESLA can be conservative and provide a false negative. To cover that, in some situations, for example single sender multicast,=20 success in group authentication may be good enough to make source=20 authentication a MAY. If this is what BOB means for a MAY (a MAY source authentication in presence of group authentication), I support it. Otherwise a MAY with failure of both source and group authentication does not=20 seem to be secure or cover any domain for Multicast secure communication. Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Elisabetta > Carrara (KI/EAB) > Sent: Monday, November 29, 2004 9:58 AM > To: Bob Briscoe; Mark Baugher > Cc: Sharma Atul (Nokia-ES/Boston); Dondeti, Lakshminath; > msec@securemulticast.org > Subject: [MSEC] RE: MUST/MAY discard > unverifiable(draft-ietf-msec-srtp-tesla-02.txt) >=20 >=20 > Bob, > I would personally read the MAY that you propose in the=20 > sentence as if the checking of the safety condition could=20 > be skipped completely.=20 > I feel comfortable only with a MUST. > If the rx's policy wants to do something else, well=20 > the protocol cannot force him otherwise (as it is local=20 > matter), as you say. >=20 > /E >=20 >=20 > >-----Original Message----- > >From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > >Sent: den 29 november 2004 00:00 > >To: Mark Baugher; Elisabetta Carrara (KI/EAB) > >Cc: msec@securemulticast.org; Atul.Sharma@nokia.com; Dondeti, > >Lakshminath > >Subject: MUST/MAY discard unverifiable > >(draft-ietf-msec-srtp-tesla-02.txt) > > > > > >Mark, Elisabetta, > > > >Returning to this subject after a long break (purely my fault)... > > > >At 19:24 14/09/2004, Mark Baugher wrote: > > > >>On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: > >> > >>>On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote: > >>>>>5/ Discard if a packet cannot be authenticated should be optional > >>>>=3D Agreed > >>> > >>>I did not sign up for this one - or at least I did not=20 > mean to. I'd > >>>like to discuss this some more. Personally, I want to=20 > limit options > >>>wherever possible and this is the second option (including=20 > making the > >>>group [MAC] optional) > >>>that you have proposed. I don't think we necessarily want=20 > >to add this > >>>particular option and would like to hear what others have to say on > >>>the matter. > >>> > >>>thanks, Mark > > > >If a packet cannot be authenticated, whether to drop it or=20 > not can be=20 > >chosen unilaterally by the receiver. It isn't a *protocol*=20 > >option. It is a=20 > >receiver choice. If it cannot be verified, it doesn't complicate the=20 > >protocol to say the receiver MAY rather than MUST drop a packet. > > > >My view remains that it is over-prescriptive to tell a=20 > >receiver it MUST=20 > >drop a packet. Indeed, whatever we say in the RFC,=20 > >applications will be=20 > >free to do what they like. The balance between the value of=20 > >rendering-quality and authenticity is up to the application, not us. > > > >Quoting the RFC Editor's policy: > >"...Imperatives ... MUST only be used where it is actually=20 > >required for=20 > >interoperation or to limit behavior which has potential for=20 > >causing harm=20 > >(e.g., limiting retransmissions). For example, they must not=20 > >be used to try=20 > >to impose a particular method on implementors where the=20 > method is not=20 > >required for interoperability." > > > > --- > > > >But there *is* a potential protocol issue here (which applies to all=20 > >authentication protocols, IPsec as much as TESLA).=20 > >Application(s) 'above'=20 > >verification in the stack (e.g. rendering, congestion control,=20 > >intrustion=20 > >detection) may need to distinguish the difference between=20 > >discard due to: > >- congestion/corruption > >- proven malicious attack > >- indeterminate authentication (in TESLA due to network delay=20 > >*or* an attack) > > > >For intrustion detection, these can be distinguished by=20 > >logging different=20 > >types of security event, as specified in the srtp-tesla draft. > > > >But, congestion control usually works purely on packet=20 > >delivery (I don't=20 > >think SRTP says anything about whether verification is done=20 > >before or after=20 > >congestion control). > > > >Yes, proven attack packets should be discarded (after=20 > >logging), because=20 > >they aren't part of the stream sent by the genuine sender. But=20 > >if packets=20 > >can't be verified they shouldn't necessarily just be discarded: > >- If they were genuine packets, congestion control will=20 > >respond wrongly if=20 > >they *are* discarded > >- If they were attack packets, congestion control will respond=20 > >wrongly if=20 > >they *aren't* discarded. > > > >Of course, the same is true of rendering: > >- If they were genuine packets, rendering will respond=20 > wrongly if they=20 > >*are* discarded > >- If they were attack packets, rendering will respond=20 > wrongly if they=20 > >*aren't* discarded. > > > >So, in order not to complicate the spec, I still maintain we=20 > >should say (in=20 > >section 4.4) > > > > > >"...If the safe condition does not hold, the packet MAY [not MUST] be > > discarded, and the event SHOULD be logged." > > > > > > > >In these cases, it is up to the receiving system to decide=20 > >whether such=20 > >packets are more likely to be genuine or malicious, choosing=20 > >whether to use=20 > >or discard the packet. With consequent consistent effects on=20 > >congestion=20 > >control, rendering etc. > > > >There is a natural tendency for security people to be=20 > >conservative under=20 > >uncertainty. But we have to remember security must be balanced=20 > >by usability. > > > >Bob > > > >_______________________________________________________________ > >_____________ > >Bob Briscoe, Networks Research=20 > >Centre, BT Research > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 > >+44 1473 645196=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 Fri Dec 3 12:31:59 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 MAA01811 for ; Fri, 3 Dec 2004 12:31:58 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 81CE68DCDD; Fri, 3 Dec 2004 12:31:58 -0500 (EST) 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 E13908DCB9 for ; Fri, 3 Dec 2004 12:31:57 -0500 (EST) Received: (qmail 69791 invoked by uid 3269); 3 Dec 2004 17:31:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69788 invoked from network); 3 Dec 2004 17:31:56 -0000 Received: from smtp1.smtp.bt.com (217.32.164.137) by klesh.pair.com with SMTP; 3 Dec 2004 17:31:56 -0000 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 3 Dec 2004 17:33:10 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Dec 2004 17:33:10 +0000 Received: from mbibipnt12.domain1.systemhost.net ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Dec 2004 17:33:06 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by mbibipnt12.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1102094994135; Fri, 3 Dec 2004 17:29:54 +0000 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 iB3HSZP3008846; Fri, 3 Dec 2004 17:28:38 GMT Message-Id: <5.2.1.1.2.20041203171619.01ba56f8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Dec 2004 17:29:05 +0000 To: "Elisabetta Carrara (KI/EAB)" From: Bob Briscoe In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD653ADE06@esealmw106.eemea.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Dec 2004 17:33:07.0901 (UTC) FILETIME=[271446D0:01C4D95E] Cc: "Dondeti, Lakshminath" , Atul.Sharma@nokia.com, Mark Baugher , msec@securemulticast.org Subject: [MSEC] RE: MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla-02.txt) 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, Ah yes, I see the confusion. This actually raises a further point. The draft only states what to do if TESLA verification fails. But there are actually 4 security tests within TESLA verification: 1. safety; 2. (not relevant to this discussion) 3. key verification; 4. message verification. I should have been clearer in explaining that I am talking about the safety test (which determines whether the packet has arrived early enough for verification to be possible). If that fails then we MAY discard. If either of the other two tests fail, then we MUST discard. I am about to upload draft 04 of the tesla intro, which explicitly names the 4 steps in TESLA receiver verification (they were in the previous draft, but not explicitly enumerated). Bob At 14:58 29/11/2004, Elisabetta Carrara \(KI/EAB\) wrote: >Bob, >I would personally read the MAY that you propose in the >sentence as if the checking of the safety condition could >be skipped completely. >I feel comfortable only with a MUST. >If the rx's policy wants to do something else, well >the protocol cannot force him otherwise (as it is local >matter), as you say. > >/E > > > >-----Original Message----- > >From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > >Sent: den 29 november 2004 00:00 > >To: Mark Baugher; Elisabetta Carrara (KI/EAB) > >Cc: msec@securemulticast.org; Atul.Sharma@nokia.com; Dondeti, > >Lakshminath > >Subject: MUST/MAY discard unverifiable > >(draft-ietf-msec-srtp-tesla-02.txt) > > > > > >Mark, Elisabetta, > > > >Returning to this subject after a long break (purely my fault)... > > > >At 19:24 14/09/2004, Mark Baugher wrote: > > > >>On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: > >> > >>>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 [MAC] 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 > > > >If a packet cannot be authenticated, whether to drop it or not can be > >chosen unilaterally by the receiver. It isn't a *protocol* > >option. It is a > >receiver choice. If it cannot be verified, it doesn't complicate the > >protocol to say the receiver MAY rather than MUST drop a packet. > > > >My view remains that it is over-prescriptive to tell a > >receiver it MUST > >drop a packet. Indeed, whatever we say in the RFC, > >applications will be > >free to do what they like. The balance between the value of > >rendering-quality and authenticity is up to the application, not us. > > > >Quoting the RFC Editor's policy: > >"...Imperatives ... MUST only be used where it is actually > >required for > >interoperation or to limit behavior which has potential for > >causing harm > >(e.g., limiting retransmissions). For example, they must not > >be used to try > >to impose a particular method on implementors where the method is not > >required for interoperability." > > > > --- > > > >But there *is* a potential protocol issue here (which applies to all > >authentication protocols, IPsec as much as TESLA). > >Application(s) 'above' > >verification in the stack (e.g. rendering, congestion control, > >intrustion > >detection) may need to distinguish the difference between > >discard due to: > >- congestion/corruption > >- proven malicious attack > >- indeterminate authentication (in TESLA due to network delay > >*or* an attack) > > > >For intrustion detection, these can be distinguished by > >logging different > >types of security event, as specified in the srtp-tesla draft. > > > >But, congestion control usually works purely on packet > >delivery (I don't > >think SRTP says anything about whether verification is done > >before or after > >congestion control). > > > >Yes, proven attack packets should be discarded (after > >logging), because > >they aren't part of the stream sent by the genuine sender. But > >if packets > >can't be verified they shouldn't necessarily just be discarded: > >- If they were genuine packets, congestion control will > >respond wrongly if > >they *are* discarded > >- If they were attack packets, congestion control will respond > >wrongly if > >they *aren't* discarded. > > > >Of course, the same is true of rendering: > >- If they were genuine packets, rendering will respond wrongly if they > >*are* discarded > >- If they were attack packets, rendering will respond wrongly if they > >*aren't* discarded. > > > >So, in order not to complicate the spec, I still maintain we > >should say (in > >section 4.4) > > > > > >"...If the safe condition does not hold, the packet MAY [not MUST] be > > discarded, and the event SHOULD be logged." > > > > > > > >In these cases, it is up to the receiving system to decide > >whether such > >packets are more likely to be genuine or malicious, choosing > >whether to use > >or discard the packet. With consequent consistent effects on > >congestion > >control, rendering etc. > > > >There is a natural tendency for security people to be > >conservative under > >uncertainty. But we have to remember security must be balanced > >by usability. > > > >Bob > > > >_______________________________________________________________ > >_____________ > >Bob Briscoe, Networks Research > >Centre, BT Research > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > >+44 1473 645196 > > > > ____________________________________________________________________________ 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 Fri Dec 3 12:39:45 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 MAA03573 for ; Fri, 3 Dec 2004 12:39:44 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C2D368D74B; Fri, 3 Dec 2004 12:39:46 -0500 (EST) 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 495778D6D4 for ; Fri, 3 Dec 2004 12:39:46 -0500 (EST) Received: (qmail 71328 invoked by uid 3269); 3 Dec 2004 17:39:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71325 invoked from network); 3 Dec 2004 17:39:45 -0000 Received: from smtp5.smtp.bt.com (217.32.164.139) by klesh.pair.com with SMTP; 3 Dec 2004 17:39:45 -0000 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 3 Dec 2004 17:41:00 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Dec 2004 17:40:59 +0000 Received: from mbibipnt12.domain1.systemhost.net ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Dec 2004 17:40:58 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by mbibipnt12.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1102095517615; Fri, 3 Dec 2004 17:38:37 +0000 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 iB3HbKP3008935; Fri, 3 Dec 2004 17:37:22 GMT Message-Id: <5.2.1.1.2.20041203170225.03b31508@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Dec 2004 17:37:49 +0000 To: "Dondeti, Lakshminath" From: Bob Briscoe Subject: Re: [MSEC] MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla- 02.txt) In-Reply-To: <41AC9E70.4080101@nortelnetworks.com> References: <5.2.1.1.2.20041127121743.03638730@pop3.jungle.bt.co.uk> <5.2.1.1.2.20041127121743.03638730@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Dec 2004 17:40:58.0482 (UTC) FILETIME=[3F913D20:01C4D95F] Cc: Atul.Sharma@nokia.com, 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 Lakshminath, At 16:23 30/11/2004, Dondeti, Lakshminath wrote: >I would use - as you also mention - IPsec RFCs as a guideline. RFC2402 >says "MUST discard" if the ICV test fails. In the same spirit, if 'TESLA >verifications' fail, the MSEC-SRTP-TESLA spec should say that the receiver >MUST discard packets. I should have made it clearer that I am discussing the case concerning inability to verify, not failure of verification. This condition doesn't arise in unicast IPsec, so I don't think we can turn to it for guidance. >The other guideline I would cite is from Section 4.4 of RFC 2401, > >"compliant implementations need not match details of this model as >presented, but the external behavior of such implementations must be >mappable to the externally observable characteristics of this model." > >Given all that, and if the TESLA spec says "MAY" then some receivers might >end up with a different copy of the stream than others, with all >implementations being "RFC-compliant"; and that is unacceptable! I am deliberately advocating that each receiver's verifier should be allowed to present different results to the next layer. In multicast this is the norm - eg different branches of a multicast tree see uncorrelated losses, and usually reliable multicast isn't used in RTP, so each receiver sees a different stream. As I just explained to Elisabetta, receiver verification actually involves 4 steps. I am only advocating "MAY discard" for one: the delay safety test. If that fails, TESLA cannot verify packets (ie nothing can be proved about verification, as opposed it can be proved a packet has failed verification). Even if we said "MUST discard" here, different delays on different branches could lead to each receiver discarding different sets of packets. Different receivers should be able to choose whether they take a risk when the authentication mechanism can tell them nothing about authenticity. Unicast IPsec can't help us as it has deterministic verification. Indeterminate verification is a new situtation that TESLA introduces. So we have to go back to first principles and think what various applications might want. Bob >regards, >Lakshminath > >Bob Briscoe wrote: > >>Mark, Elisabetta, >> >>Returning to this subject after a long break (purely my fault)... >> >>At 19:24 14/09/2004, Mark Baugher wrote: >> >> >On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: >> > >> >>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 [MAC] 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 >> >>If a packet cannot be authenticated, whether to drop it or not can be >>chosen unilaterally by the receiver. It isn't a *protocol* option. It is a >>receiver choice. If it cannot be verified, it doesn't complicate the >>protocol to say the receiver MAY rather than MUST drop a packet. >> >>My view remains that it is over-prescriptive to tell a receiver it MUST >>drop a packet. Indeed, whatever we say in the RFC, applications will be >>free to do what they like. The balance between the value of >>rendering-quality and authenticity is up to the application, not us. >> >>Quoting the RFC Editor's policy: >>"...Imperatives ... MUST only be used where it is actually required for >>interoperation or to limit behavior which has potential for causing harm >>(e.g., limiting retransmissions). For example, they must not be used to try >>to impose a particular method on implementors where the method is not >>required for interoperability." >> >> --- >> >>But there *is* a potential protocol issue here (which applies to all >>authentication protocols, IPsec as much as TESLA). Application(s) 'above' >>verification in the stack (e.g. rendering, congestion control, intrustion >>detection) may need to distinguish the difference between discard due to: >>- congestion/corruption >>- proven malicious attack >>- indeterminate authentication (in TESLA due to network delay *or* an attack) >> >>For intrustion detection, these can be distinguished by logging different >>types of security event, as specified in the srtp-tesla draft. >> >>But, congestion control usually works purely on packet delivery (I don't >>think SRTP says anything about whether verification is done before or after >>congestion control). >> >>Yes, proven attack packets should be discarded (after logging), because >>they aren't part of the stream sent by the genuine sender. But if packets >>can't be verified they shouldn't necessarily just be discarded: >>- If they were genuine packets, congestion control will respond wrongly if >>they *are* discarded >>- If they were attack packets, congestion control will respond wrongly if >>they *aren't* discarded. >> >>Of course, the same is true of rendering: >>- If they were genuine packets, rendering will respond wrongly if they >>*are* discarded >>- If they were attack packets, rendering will respond wrongly if they >>*aren't* discarded. >> >>So, in order not to complicate the spec, I still maintain we should say (in >>section 4.4) >> >> >>"...If the safe condition does not hold, the packet MAY [not MUST] be >> discarded, and the event SHOULD be logged." >> >> >> >>In these cases, it is up to the receiving system to decide whether such >>packets are more likely to be genuine or malicious, choosing whether to use >>or discard the packet. With consequent consistent effects on congestion >>control, rendering etc. >> >>There is a natural tendency for security people to be conservative under >>uncertainty. But we have to remember security must be balanced by usability. >> >>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 > >____________________________________________________________________________ >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 Fri Dec 3 12:40:26 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 MAA03825 for ; Fri, 3 Dec 2004 12:40:25 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6ABA08CC34; Fri, 3 Dec 2004 12:40:27 -0500 (EST) 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 1FCF38CBB0 for ; Fri, 3 Dec 2004 12:40:26 -0500 (EST) Received: (qmail 71580 invoked by uid 3269); 3 Dec 2004 17:40:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71577 invoked from network); 3 Dec 2004 17:40:25 -0000 Received: from smtp2.smtp.bt.com (217.32.164.150) by klesh.pair.com with SMTP; 3 Dec 2004 17:40:25 -0000 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 3 Dec 2004 17:41:39 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Dec 2004 17:41:38 +0000 Received: from mbibipnt12.domain1.systemhost.net ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Dec 2004 17:41:38 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by mbibipnt12.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1102095604940; Fri, 3 Dec 2004 17:40:04 +0000 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 iB3HclP3008944; Fri, 3 Dec 2004 17:38:49 GMT Message-Id: <5.2.1.1.2.20041203163951.03b8ca70@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Dec 2004 17:38:54 +0000 To: From: Bob Briscoe Subject: RE: [MSEC] RE: MUST/MAY discard unverifiable(draft-ietf-msec-srtp-tesla-02.txt) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Dec 2004 17:41:38.0404 (UTC) FILETIME=[575CDA40:01C4D95F] Cc: ldondeti@nortelnetworks.com, 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, I think there's some confusion here (my fault for leaving such a long delay in my response to an old thread). I'm not talking about *failure* of source authentication. I'm talking about *inability* to source authenticate (because too much time has elapsed since the packet was sent before it is received, so the packet could be bogus but it might be genuine). If there has been no evidence of any verification *failure* during the whole stream, there may be little reason to discard certain packets just because they arrive too late to be verified. Yes, an intermediate router could be compromised and delay packets until it can pick up TESLA keys to spoof them. But if router compromise is considered unlikely, the receiving application might want to decide to take the risk (perhaps with some flag to the user, so the user can assess the risk). But, otherwise, I agree that if group authentication has failed the packet MUST be discarded and the event SHOULD be logged, without even bothering to do source authentication. Mark & Elisabetta's draft makes this order of tests and outcomes very clear already. Bob At 16:45 01/12/2004, Atul.Sharma@nokia.com wrote: >IMO, generally if neither source authentication nor group >authentication succeeds, we MUST discard the packet. A MAY >for failure of source authentication can be accepted in >certain situations provided there is a group authentication >success. > >TESLA can be conservative and provide a false negative. To cover >that, in some situations, for example single sender multicast, >success in group authentication may be good enough to make source >authentication a MAY. > >If this is what BOB means for a MAY (a MAY source authentication >in presence of group authentication), I support it. Otherwise a >MAY with failure of both source and group authentication does not >seem to be secure or cover any domain for Multicast secure >communication. > >Atul > > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Elisabetta > > Carrara (KI/EAB) > > Sent: Monday, November 29, 2004 9:58 AM > > To: Bob Briscoe; Mark Baugher > > Cc: Sharma Atul (Nokia-ES/Boston); Dondeti, Lakshminath; > > msec@securemulticast.org > > Subject: [MSEC] RE: MUST/MAY discard > > unverifiable(draft-ietf-msec-srtp-tesla-02.txt) > > > > > > Bob, > > I would personally read the MAY that you propose in the > > sentence as if the checking of the safety condition could > > be skipped completely. > > I feel comfortable only with a MUST. > > If the rx's policy wants to do something else, well > > the protocol cannot force him otherwise (as it is local > > matter), as you say. > > > > /E > > > > > > >-----Original Message----- > > >From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > >Sent: den 29 november 2004 00:00 > > >To: Mark Baugher; Elisabetta Carrara (KI/EAB) > > >Cc: msec@securemulticast.org; Atul.Sharma@nokia.com; Dondeti, > > >Lakshminath > > >Subject: MUST/MAY discard unverifiable > > >(draft-ietf-msec-srtp-tesla-02.txt) > > > > > > > > >Mark, Elisabetta, > > > > > >Returning to this subject after a long break (purely my fault)... > > > > > >At 19:24 14/09/2004, Mark Baugher wrote: > > > > > >>On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: > > >> > > >>>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 [MAC] 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 > > > > > >If a packet cannot be authenticated, whether to drop it or > > not can be > > >chosen unilaterally by the receiver. It isn't a *protocol* > > >option. It is a > > >receiver choice. If it cannot be verified, it doesn't complicate the > > >protocol to say the receiver MAY rather than MUST drop a packet. > > > > > >My view remains that it is over-prescriptive to tell a > > >receiver it MUST > > >drop a packet. Indeed, whatever we say in the RFC, > > >applications will be > > >free to do what they like. The balance between the value of > > >rendering-quality and authenticity is up to the application, not us. > > > > > >Quoting the RFC Editor's policy: > > >"...Imperatives ... MUST only be used where it is actually > > >required for > > >interoperation or to limit behavior which has potential for > > >causing harm > > >(e.g., limiting retransmissions). For example, they must not > > >be used to try > > >to impose a particular method on implementors where the > > method is not > > >required for interoperability." > > > > > > --- > > > > > >But there *is* a potential protocol issue here (which applies to all > > >authentication protocols, IPsec as much as TESLA). > > >Application(s) 'above' > > >verification in the stack (e.g. rendering, congestion control, > > >intrustion > > >detection) may need to distinguish the difference between > > >discard due to: > > >- congestion/corruption > > >- proven malicious attack > > >- indeterminate authentication (in TESLA due to network delay > > >*or* an attack) > > > > > >For intrustion detection, these can be distinguished by > > >logging different > > >types of security event, as specified in the srtp-tesla draft. > > > > > >But, congestion control usually works purely on packet > > >delivery (I don't > > >think SRTP says anything about whether verification is done > > >before or after > > >congestion control). > > > > > >Yes, proven attack packets should be discarded (after > > >logging), because > > >they aren't part of the stream sent by the genuine sender. But > > >if packets > > >can't be verified they shouldn't necessarily just be discarded: > > >- If they were genuine packets, congestion control will > > >respond wrongly if > > >they *are* discarded > > >- If they were attack packets, congestion control will respond > > >wrongly if > > >they *aren't* discarded. > > > > > >Of course, the same is true of rendering: > > >- If they were genuine packets, rendering will respond > > wrongly if they > > >*are* discarded > > >- If they were attack packets, rendering will respond > > wrongly if they > > >*aren't* discarded. > > > > > >So, in order not to complicate the spec, I still maintain we > > >should say (in > > >section 4.4) > > > > > > > > >"...If the safe condition does not hold, the packet MAY [not MUST] be > > > discarded, and the event SHOULD be logged." > > > > > > > > > > > >In these cases, it is up to the receiving system to decide > > >whether such > > >packets are more likely to be genuine or malicious, choosing > > >whether to use > > >or discard the packet. With consequent consistent effects on > > >congestion > > >control, rendering etc. > > > > > >There is a natural tendency for security people to be > > >conservative under > > >uncertainty. But we have to remember security must be balanced > > >by usability. > > > > > >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 > > ____________________________________________________________________________ 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 Fri Dec 3 14:20:44 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 OAA24061 for ; Fri, 3 Dec 2004 14:20:43 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 798178E10D; Fri, 3 Dec 2004 14:20:44 -0500 (EST) 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 A06508E0C8 for ; Fri, 3 Dec 2004 14:20:42 -0500 (EST) Received: (qmail 88903 invoked by uid 3269); 3 Dec 2004 19:20:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88900 invoked from network); 3 Dec 2004 19:20:42 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by klesh.pair.com with SMTP; 3 Dec 2004 19:20:42 -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 iB3JKTi23888; Fri, 3 Dec 2004 14:20:29 -0500 (EST) 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 WKL3MVMV; Fri, 3 Dec 2004 14:20:29 -0500 Message-ID: <41B0BC7C.8090702@nortelnetworks.com> Date: Fri, 03 Dec 2004 14:20:28 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [MSEC] MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla- 02.txt) References: <5.2.1.1.2.20041203170225.03b31508@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20041203170225.03b31508@pop3.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Atul.Sharma@nokia.com, "cane >> Ran Canetti" , housley@vigilsec.com, msec@securemulticast.org, elisabetta.carrara@ericsson.com, Thomas Hardjono , Mark Baugher 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, Many thanks for your comments. Yes, indeed multicast receivers may in fact have different copies of a stream. However, if we follow strict guidelines in verifying their integrity, we know for sure that each receiver's stream was in fact sent by the claimed sender. However, if we suggest the "MAY" guideline, it is plausible that some receivers (or may be all) have a copy that is (in part) bogus. Perhaps, we should just write that "receivers must (not MUST, since as you note correctly that this is a local matter) drop packets if they fail TESLA verifications." Or better yet, I would ask the chairs and the AD/Adviser for guidance here. We have been arguing this forever. regards, Lakshminath Bob Briscoe wrote: > Lakshminath, > > At 16:23 30/11/2004, Dondeti, Lakshminath wrote: > >I would use - as you also mention - IPsec RFCs as a guideline. RFC2402 > >says "MUST discard" if the ICV test fails. In the same spirit, if > 'TESLA > >verifications' fail, the MSEC-SRTP-TESLA spec should say that the > receiver > >MUST discard packets. > > I should have made it clearer that I am discussing the case concerning > inability to verify, not failure of verification. > > This condition doesn't arise in unicast IPsec, so I don't think we can > turn > to it for guidance. > > >The other guideline I would cite is from Section 4.4 of RFC 2401, > > > >"compliant implementations need not match details of this model as > >presented, but the external behavior of such implementations must be > >mappable to the externally observable characteristics of this model." > > > >Given all that, and if the TESLA spec says "MAY" then some receivers > might > >end up with a different copy of the stream than others, with all > >implementations being "RFC-compliant"; and that is unacceptable! > > I am deliberately advocating that each receiver's verifier should be > allowed to present different results to the next layer. In multicast this > is the norm - eg different branches of a multicast tree see uncorrelated > losses, and usually reliable multicast isn't used in RTP, so each > receiver > sees a different stream. > > As I just explained to Elisabetta, receiver verification actually > involves > 4 steps. I am only advocating "MAY discard" for one: the delay safety > test. > If that fails, TESLA cannot verify packets (ie nothing can be proved > about > verification, as opposed it can be proved a packet has failed > verification). Even if we said "MUST discard" here, different delays on > different branches could lead to each receiver discarding different > sets of > packets. > > Different receivers should be able to choose whether they take a risk > when > the authentication mechanism can tell them nothing about authenticity. > Unicast IPsec can't help us as it has deterministic verification. > Indeterminate verification is a new situtation that TESLA introduces. > So we > have to go back to first principles and think what various applications > might want. > > > > Bob > > >regards, > >Lakshminath > > > >Bob Briscoe wrote: > > > >>Mark, Elisabetta, > >> > >>Returning to this subject after a long break (purely my fault)... > >> > >>At 19:24 14/09/2004, Mark Baugher wrote: > >> > >> >On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: > >> > > >> >>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 [MAC] 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 > >> > >>If a packet cannot be authenticated, whether to drop it or not can be > >>chosen unilaterally by the receiver. It isn't a *protocol* option. > It is a > >>receiver choice. If it cannot be verified, it doesn't complicate the > >>protocol to say the receiver MAY rather than MUST drop a packet. > >> > >>My view remains that it is over-prescriptive to tell a receiver it MUST > >>drop a packet. Indeed, whatever we say in the RFC, applications will be > >>free to do what they like. The balance between the value of > >>rendering-quality and authenticity is up to the application, not us. > >> > >>Quoting the RFC Editor's policy: > >>"...Imperatives ... MUST only be used where it is actually required for > >>interoperation or to limit behavior which has potential for causing > harm > >>(e.g., limiting retransmissions). For example, they must not be used > to try > >>to impose a particular method on implementors where the method is not > >>required for interoperability." > >> > >> --- > >> > >>But there *is* a potential protocol issue here (which applies to all > >>authentication protocols, IPsec as much as TESLA). Application(s) > 'above' > >>verification in the stack (e.g. rendering, congestion control, > intrustion > >>detection) may need to distinguish the difference between discard > due to: > >>- congestion/corruption > >>- proven malicious attack > >>- indeterminate authentication (in TESLA due to network delay *or* > an attack) > >> > >>For intrustion detection, these can be distinguished by logging > different > >>types of security event, as specified in the srtp-tesla draft. > >> > >>But, congestion control usually works purely on packet delivery (I > don't > >>think SRTP says anything about whether verification is done before > or after > >>congestion control). > >> > >>Yes, proven attack packets should be discarded (after logging), because > >>they aren't part of the stream sent by the genuine sender. But if > packets > >>can't be verified they shouldn't necessarily just be discarded: > >>- If they were genuine packets, congestion control will respond > wrongly if > >>they *are* discarded > >>- If they were attack packets, congestion control will respond > wrongly if > >>they *aren't* discarded. > >> > >>Of course, the same is true of rendering: > >>- If they were genuine packets, rendering will respond wrongly if they > >>*are* discarded > >>- If they were attack packets, rendering will respond wrongly if they > >>*aren't* discarded. > >> > >>So, in order not to complicate the spec, I still maintain we should > say (in > >>section 4.4) > >> > >> > >>"...If the safe condition does not hold, the packet MAY [not MUST] be > >> discarded, and the event SHOULD be logged." > >> > >> > >> > >>In these cases, it is up to the receiving system to decide whether such > >>packets are more likely to be genuine or malicious, choosing whether > to use > >>or discard the packet. With consequent consistent effects on congestion > >>control, rendering etc. > >> > >>There is a natural tendency for security people to be conservative > under > >>uncertainty. But we have to remember security must be balanced by > usability. > >> > >>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 > > > >____________________________________________________________________________ > > >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 Mon Dec 6 22:52:50 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 WAA25776 for ; Mon, 6 Dec 2004 22:52:50 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CBADE8CF63; Mon, 6 Dec 2004 22:52:14 -0500 (EST) 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 872698CD5B for ; Mon, 6 Dec 2004 22:52:13 -0500 (EST) Received: (qmail 84263 invoked by uid 3269); 7 Dec 2004 03:52:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84260 invoked from network); 7 Dec 2004 03:52:13 -0000 Received: from smtp4.smtp.bt.com (217.32.164.151) by klesh.pair.com with SMTP; 7 Dec 2004 03:52:13 -0000 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 7 Dec 2004 03:53:28 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Dec 2004 03:53:28 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Dec 2004 03:53:27 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a); id 1102391530145; Tue, 7 Dec 2004 03:52:10 +0000 Received: from mut.jungle.bt.co.uk ([132.146.136.69]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id iB73p6P3027638; Tue, 7 Dec 2004 03:52:08 GMT Message-Id: <5.2.1.1.2.20041207022658.02ed7898@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 07 Dec 2004 03:51:38 +0000 To: "Dondeti, Lakshminath" From: Bob Briscoe Subject: Re: [MSEC] MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla- 02.txt) In-Reply-To: <41B0BC7C.8090702@nortelnetworks.com> References: <5.2.1.1.2.20041203170225.03b31508@pop3.jungle.bt.co.uk> <5.2.1.1.2.20041203170225.03b31508@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Dec 2004 03:53:27.0056 (UTC) FILETIME=[4EA9E100:01C4DC10] Cc: Atul.Sharma@nokia.com, "cane >> Ran Canetti" , housley@vigilsec.com, msec@securemulticast.org, elisabetta.carrara@ericsson.com, Thomas Hardjono , Mark Baugher 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 Lakshminath, At 19:20 03/12/2004, Dondeti, Lakshminath wrote: >Bob, > >Many thanks for your comments. Yes, indeed multicast receivers may in >fact have different copies of a stream. However, if we follow strict >guidelines in verifying their integrity, we know for sure that each >receiver's stream was in fact sent by the claimed sender. >However, if we suggest the "MAY" guideline, it is plausible that some >receivers (or may be all) have a copy that is (in part) bogus. But if I don't know for sure whether some packets in a stream were sent by the claimed sender, do you have the right to tell me to discard them? I may have a job to do. Authenticity is but one of my considerations. The closest everyday analogy I can think of is accessing a Web page through SSL, and being warned by the browser that the certificate has expired. Would it have been correct for the SSL spec to say packets MUST be discarded if they are protected by an expired key? But the analogy isn't perfect, because in TESLA the unsafe condition gives no protection at all... >Perhaps, we should just write that "receivers must (not MUST, since as you >note correctly that this is a local matter) drop packets if they fail >TESLA verifications." This doesn't seem to solve anything. I don't quite see why we say they must then? >Or better yet, I would ask the chairs and the AD/Adviser for guidance >here. We have been arguing this forever. Please do. I'm repeating the same arguments, over. The only reason I'm continuing, is because originally, I deliberately designed TESLA along open architecture principles, which can be closed if required (whereas the reverse isn't true). If you define a protocol for receivers to be loosely coupled, an application can be defined that tightly couples them, but not the other way round. So I'm loathe to see (perfectly legitimate) interest in tightly coupled design closing off what I consider as elegant protocol design - one which allows both styles to co-exist. If the w-g chairs consider it necessary to go to the AD/Adviser, here's as brief and precise a statement as I can muster of what I believe is the problem: \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ TESLA provides a robust, lightweight solution to what is considered a hard problem: multicast source authentication. However, the typical TESLA verification mechanism cannot verify any packet that is delayed beyond a predefined disclosure delay. Packet delay may be caused by an attacker, but it can also be quite common on the Internet. So a receiver cannot be certain whether delay is routine or suspicious. Therefore, if packets have been delayed beyond a threshold, they effectively have to be treated as if authentication hadn't been applied. Even though the sender considered TESLA source authentication necessary. In the process of standardising TESLA for use in secure multicast RTP, some in the working group believe we should mandate that packets delayed beyond this threshold MUST be discarded. Others believe we should recommend that they SHOULD be discarded, but that the receiver may choose to use them at its own risk. The "MUST discard" position is justified on protocol safety grounds, making the meaning of packet delivery unambiguous, with no packets being delivered unless they are positively verified. The "SHOULD discard" position is justified on the grounds of receiver autonomy: so that some may choose to use unverifiable packets if their need outweighs the risk, but that usually they shouldn't. Is there guidance on which of these two concerns is paramount? Or is there another textual device to reconcile these two positions? \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Cheers Bob >regards, >Lakshminath > >Bob Briscoe wrote: > >>Lakshminath, >> >>At 16:23 30/11/2004, Dondeti, Lakshminath wrote: >> >I would use - as you also mention - IPsec RFCs as a guideline. RFC2402 >> >says "MUST discard" if the ICV test fails. In the same spirit, if 'TESLA >> >verifications' fail, the MSEC-SRTP-TESLA spec should say that the receiver >> >MUST discard packets. >> >>I should have made it clearer that I am discussing the case concerning >>inability to verify, not failure of verification. >> >>This condition doesn't arise in unicast IPsec, so I don't think we can turn >>to it for guidance. >> >> >The other guideline I would cite is from Section 4.4 of RFC 2401, >> > >> >"compliant implementations need not match details of this model as >> >presented, but the external behavior of such implementations must be >> >mappable to the externally observable characteristics of this model." >> > >> >Given all that, and if the TESLA spec says "MAY" then some receivers might >> >end up with a different copy of the stream than others, with all >> >implementations being "RFC-compliant"; and that is unacceptable! >> >>I am deliberately advocating that each receiver's verifier should be >>allowed to present different results to the next layer. In multicast this >>is the norm - eg different branches of a multicast tree see uncorrelated >>losses, and usually reliable multicast isn't used in RTP, so each receiver >>sees a different stream. >> >>As I just explained to Elisabetta, receiver verification actually involves >>4 steps. I am only advocating "MAY discard" for one: the delay safety test. >>If that fails, TESLA cannot verify packets (ie nothing can be proved about >>verification, as opposed it can be proved a packet has failed >>verification). Even if we said "MUST discard" here, different delays on >>different branches could lead to each receiver discarding different sets of >>packets. >> >>Different receivers should be able to choose whether they take a risk when >>the authentication mechanism can tell them nothing about authenticity. >>Unicast IPsec can't help us as it has deterministic verification. >>Indeterminate verification is a new situtation that TESLA introduces. So we >>have to go back to first principles and think what various applications >>might want. >> >> >> >>Bob >> >> >regards, >> >Lakshminath >> > >> >Bob Briscoe wrote: >> > >> >>Mark, Elisabetta, >> >> >> >>Returning to this subject after a long break (purely my fault)... >> >> >> >>At 19:24 14/09/2004, Mark Baugher wrote: >> >> >> >> >On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote: >> >> > >> >> >>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 [MAC] 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 >> >> >> >>If a packet cannot be authenticated, whether to drop it or not can be >> >>chosen unilaterally by the receiver. It isn't a *protocol* option. It is a >> >>receiver choice. If it cannot be verified, it doesn't complicate the >> >>protocol to say the receiver MAY rather than MUST drop a packet. >> >> >> >>My view remains that it is over-prescriptive to tell a receiver it MUST >> >>drop a packet. Indeed, whatever we say in the RFC, applications will be >> >>free to do what they like. The balance between the value of >> >>rendering-quality and authenticity is up to the application, not us. >> >> >> >>Quoting the RFC Editor's policy: >> >>"...Imperatives ... MUST only be used where it is actually required for >> >>interoperation or to limit behavior which has potential for causing harm >> >>(e.g., limiting retransmissions). For example, they must not be used >> to try >> >>to impose a particular method on implementors where the method is not >> >>required for interoperability." >> >> >> >> --- >> >> >> >>But there *is* a potential protocol issue here (which applies to all >> >>authentication protocols, IPsec as much as TESLA). Application(s) 'above' >> >>verification in the stack (e.g. rendering, congestion control, intrustion >> >>detection) may need to distinguish the difference between discard due to: >> >>- congestion/corruption >> >>- proven malicious attack >> >>- indeterminate authentication (in TESLA due to network delay *or* an >> attack) >> >> >> >>For intrustion detection, these can be distinguished by logging different >> >>types of security event, as specified in the srtp-tesla draft. >> >> >> >>But, congestion control usually works purely on packet delivery (I don't >> >>think SRTP says anything about whether verification is done before or >> after >> >>congestion control). >> >> >> >>Yes, proven attack packets should be discarded (after logging), because >> >>they aren't part of the stream sent by the genuine sender. But if packets >> >>can't be verified they shouldn't necessarily just be discarded: >> >>- If they were genuine packets, congestion control will respond wrongly if >> >>they *are* discarded >> >>- If they were attack packets, congestion control will respond wrongly if >> >>they *aren't* discarded. >> >> >> >>Of course, the same is true of rendering: >> >>- If they were genuine packets, rendering will respond wrongly if they >> >>*are* discarded >> >>- If they were attack packets, rendering will respond wrongly if they >> >>*aren't* discarded. >> >> >> >>So, in order not to complicate the spec, I still maintain we should >> say (in >> >>section 4.4) >> >> >> >> >> >>"...If the safe condition does not hold, the packet MAY [not MUST] be >> >> discarded, and the event SHOULD be logged." >> >> >> >> >> >> >> >>In these cases, it is up to the receiving system to decide whether such >> >>packets are more likely to be genuine or malicious, choosing whether >> to use >> >>or discard the packet. With consequent consistent effects on congestion >> >>control, rendering etc. >> >> >> >>There is a natural tendency for security people to be conservative under >> >>uncertainty. But we have to remember security must be balanced by >> usability. >> >> >> >>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 >> > >> >________________________________________________________________________ >> ____ >> >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 >> >> > >____________________________________________________________________________ >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 Dec 9 07:21:07 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 HAA16656 for ; Thu, 9 Dec 2004 07:21:07 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C5B108D0E9; Thu, 9 Dec 2004 07:21:04 -0500 (EST) 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 F0A1F8CD6C for ; Thu, 9 Dec 2004 07:21:02 -0500 (EST) Received: (qmail 14301 invoked by uid 3269); 9 Dec 2004 12:21:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14298 invoked from network); 9 Dec 2004 12:21:02 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 9 Dec 2004 12:21:02 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iB9CL1eh031920; Thu, 9 Dec 2004 13:21:01 +0100 Received: from MCHN070C (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id iB9CKxJa019781; Thu, 9 Dec 2004 13:20:59 +0100 From: "Steffen Fries" Organization: Siemens AG To: canetti Date: Thu, 09 Dec 2004 13:20:50 +0100 MIME-Version: 1.0 Message-ID: <41B85132.27314.A2B444A@localhost> Priority: normal In-reply-to: References: <0CDAE977A7172A40A2A3A1C20C12BD653ADCF0@esealmw106.eemea.ericsson.se> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: msec@securemulticast.org, hannes.tschofenig@siemens.com Subject: [MSEC] IANA question to TESLA bootstrapping in MIKEY X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Ran, at the time being we are about writing the IANA section in the TESLA bootstrapping draft. One question that came up is the following: The current draft provides means to transport the TESLA policy between the media sender and the media receiver. We adopted the default values for MAC and PRF from the SRTP TESLA integration draft, which is HMAC-SHA1. Do you feel that it is necessary to leave the PRF and MAC function signaling in the TESLA policy open in terms of having IANA handling the registration of the further mechanisms or should we fix the values as provided in the draft? Regards Steffen ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Dec 9 14:35:29 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 OAA25054 for ; Thu, 9 Dec 2004 14:35:29 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 42CCB8D53F; Thu, 9 Dec 2004 14:35:29 -0500 (EST) 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 6B9E48D53B for ; Thu, 9 Dec 2004 14:35:27 -0500 (EST) Received: (qmail 88555 invoked by uid 3269); 9 Dec 2004 19:35:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88550 invoked from network); 9 Dec 2004 19:35:26 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 9 Dec 2004 19:35:26 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id iB9JYr3157192; Thu, 9 Dec 2004 14:34:53 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id iB9JZKB46932; Thu, 9 Dec 2004 14:35:20 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id iB9JZJA62756; Thu, 9 Dec 2004 14:35:19 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id iB9JZHj30880; Thu, 9 Dec 2004 14:35:18 -0500 Date: Thu, 9 Dec 2004 14:35:16 -0500 (EST) From: canetti To: Steffen Fries In-Reply-To: <41B85132.27314.A2B444A@localhost> Message-ID: References: <0CDAE977A7172A40A2A3A1C20C12BD653ADCF0@esealmw106.eemea.ericsson.se> <41B85132.27314.A2B444A@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: msec@securemulticast.org, hannes.tschofenig@siemens.com Subject: [MSEC] Re: IANA question to TESLA bootstrapping in MIKEY 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 Steffen, my personal impression is that the most important thing is to be compatible with SRTP TESLA, since this is today the main poteintial venue for using TELSA with MIKEY. So I'd go for the fixed version. What do others think? Ran On Thu, 9 Dec 2004, Steffen Fries wrote: > Hi Ran, > > at the time being we are about writing the IANA section in the > TESLA bootstrapping draft. One question that came up is the > following: The current draft provides means to transport the > TESLA policy between the media sender and the media receiver. We > adopted the default values for MAC and PRF from the SRTP TESLA > integration draft, which is HMAC-SHA1. Do you feel that it is > necessary to leave the PRF and MAC function signaling in the > TESLA policy open in terms of having IANA handling the > registration of the further mechanisms or should we fix the > values as provided in the draft? > > Regards > Steffen > > > > ----------------------------------------------------------- > Steffen Fries, Siemens AG, CT IC 3 > Otto-Hahn-Ring 6, D-81730 Munich, Germany > Phone: (+49) 89 / 636-53403, > Fax : (+49) 89 / 636-48000 > Email: Steffen.Fries@siemens.com > ----------------------------------------------------------- > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Dec 9 14:54:45 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 OAA26532 for ; Thu, 9 Dec 2004 14:54:45 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A3AB08CCD9; Thu, 9 Dec 2004 14:54:45 -0500 (EST) 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 C398F8C38B for ; Thu, 9 Dec 2004 14:54:43 -0500 (EST) Received: (qmail 91793 invoked by uid 3269); 9 Dec 2004 19:54:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91790 invoked from network); 9 Dec 2004 19:54:43 -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; 9 Dec 2004 19:54:43 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2004 11:57:36 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iB9JsewN002050; Thu, 9 Dec 2004 11:54:40 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn5-602.cisco.com [10.21.90.90]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB9JrdKT010334; Thu, 9 Dec 2004 11:53:39 -0800 In-Reply-To: References: <0CDAE977A7172A40A2A3A1C20C12BD653ADCF0@esealmw106.eemea.ericsson.se> <41B85132.27314.A2B444A@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <27723AB6-4A1C-11D9-A7FD-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Re: IANA question to TESLA bootstrapping in MIKEY Date: Thu, 9 Dec 2004 11:54:36 -0800 To: canetti X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102622020.132897"; x:"432200"; a:"rsa-sha1"; b:"nofws:1769"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"VRJmqChdHaAyHGrfO/athy97y0LCrrtrD0Anx+zbwfYYlVjDahh84Hl6w4MVt" "UG2Iex84Vni3udNV8bWEXhxMbjRtupiRMHeqZ9j+Fr6UoQTiqOjuuxY3WRfMp" "ldmWL8XJGwMVc5R7kPUUzK9utV0dgNAljOPXsUbbmK4k430VU="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] Re: IANA question to TESLA bootstrapping in MIKEY"; c:"Date: Thu, 9 Dec 2004 11:54:36 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: hannes.tschofenig@siemens.com, Steffen Fries , 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 Off the top of my head, I can't think of any key management protocols that don't allow algorithms to be upgraded for a security protocol. Otherwise, what happens when the default algorithm is compromised? Mark On Dec 9, 2004, at 11:35 AM, canetti wrote: > > Steffen, my personal impression is that the most important thing is to > be > compatible with SRTP TESLA, since this is today the main poteintial > venue > for using TELSA with MIKEY. So I'd go for the fixed version. > What do others think? > > Ran > > On Thu, 9 Dec 2004, Steffen Fries wrote: > >> Hi Ran, >> >> at the time being we are about writing the IANA section in the >> TESLA bootstrapping draft. One question that came up is the >> following: The current draft provides means to transport the >> TESLA policy between the media sender and the media receiver. We >> adopted the default values for MAC and PRF from the SRTP TESLA >> integration draft, which is HMAC-SHA1. Do you feel that it is >> necessary to leave the PRF and MAC function signaling in the >> TESLA policy open in terms of having IANA handling the >> registration of the further mechanisms or should we fix the >> values as provided in the draft? >> >> Regards >> Steffen >> >> >> >> ----------------------------------------------------------- >> Steffen Fries, Siemens AG, CT IC 3 >> Otto-Hahn-Ring 6, D-81730 Munich, Germany >> Phone: (+49) 89 / 636-53403, >> Fax : (+49) 89 / 636-48000 >> Email: Steffen.Fries@siemens.com >> ----------------------------------------------------------- >> >> >> > _______________________________________________ > 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 Dec 10 07:14:13 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 HAA08776 for ; Fri, 10 Dec 2004 07:14:10 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 67C788C3BD; Fri, 10 Dec 2004 07:14:12 -0500 (EST) 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 E598E8C208 for ; Fri, 10 Dec 2004 07:14:08 -0500 (EST) Received: (qmail 78525 invoked by uid 3269); 10 Dec 2004 12:14:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78521 invoked from network); 10 Dec 2004 12:14:08 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 10 Dec 2004 12:14:08 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBACE6rm000062; Fri, 10 Dec 2004 13:14:06 +0100 Received: from MCHN070C (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iBACE5mC004265; Fri, 10 Dec 2004 13:14:05 +0100 From: "Steffen Fries" Organization: Siemens AG To: canetti , Mark Baugher Date: Fri, 10 Dec 2004 13:14:04 +0100 MIME-Version: 1.0 Subject: Re: [MSEC] Re: IANA question to TESLA bootstrapping in MIKEY Message-ID: <41B9A11C.29364.B775D0@localhost> Priority: normal In-reply-to: <27723AB6-4A1C-11D9-A7FD-000A95DC10F2@cisco.com> References: X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: hannes.tschofenig@siemens.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Mark, to be more generic you are right. It might also be the case that there exist a different usecase for bootstarpping TESLA with MIKEY, which requires a different PRF and MAC as the ones currently defined. Regards Steffen Copies to: msec@securemulticast.org, hannes.tschofenig@siemens.com, Steffen Fries From: Mark Baugher Subject: Re: [MSEC] Re: IANA question to TESLA bootstrapping in MIKEY Date sent: Thu, 9 Dec 2004 11:54:36 -0800 To: canetti > Off the top of my head, I can't think of any key management protocols > that don't allow algorithms to be upgraded for a security protocol. > Otherwise, what happens when the default algorithm is compromised? > > Mark > On Dec 9, 2004, at 11:35 AM, canetti wrote: > > > > > Steffen, my personal impression is that the most important thing is > > to be compatible with SRTP TESLA, since this is today the main > > poteintial venue for using TELSA with MIKEY. So I'd go for the fixed > > version. What do others think? > > > > Ran > > > > On Thu, 9 Dec 2004, Steffen Fries wrote: > > > >> Hi Ran, > >> > >> at the time being we are about writing the IANA section in the > >> TESLA bootstrapping draft. One question that came up is the > >> following: The current draft provides means to transport the TESLA > >> policy between the media sender and the media receiver. We adopted > >> the default values for MAC and PRF from the SRTP TESLA integration > >> draft, which is HMAC-SHA1. Do you feel that it is necessary to > >> leave the PRF and MAC function signaling in the TESLA policy open > >> in terms of having IANA handling the registration of the further > >> mechanisms or should we fix the values as provided in the draft? > >> > >> Regards > >> Steffen > >> > >> > >> > >> ----------------------------------------------------------- > >> Steffen Fries, Siemens AG, CT IC 3 > >> Otto-Hahn-Ring 6, D-81730 Munich, Germany > >> Phone: (+49) 89 / 636-53403, > >> Fax : (+49) 89 / 636-48000 > >> Email: Steffen.Fries@siemens.com > >> ----------------------------------------------------------- > >> > >> > >> > > _______________________________________________ > > 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 Dec 17 03:57:50 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 DAA25632 for ; Fri, 17 Dec 2004 03:57:49 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A58D58CC1E; Fri, 17 Dec 2004 03:57:50 -0500 (EST) 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 023448CB1F for ; Fri, 17 Dec 2004 03:57:49 -0500 (EST) Received: (qmail 75438 invoked by uid 3269); 17 Dec 2004 08:57:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75435 invoked from network); 17 Dec 2004 08:57:48 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 17 Dec 2004 08:57:48 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iBH8vlkP029391 for ; Fri, 17 Dec 2004 09:57:47 +0100 Received: from MCHN070C (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iBH8vkZn023035 for ; Fri, 17 Dec 2004 09:57:46 +0100 From: "Steffen Fries" Organization: Siemens AG To: msec@securemulticast.org Date: Fri, 17 Dec 2004 09:57:42 +0100 MIME-Version: 1.0 Message-ID: <41C2AD96.4410.4E62E6C@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: [MSEC] MIKEY Question X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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've got a question to the usage of the salt and master key (TGK) delivered by MIKEY. Does MIKEY offer an option to update the salting key alone by keeping the same TGK? The question behind that is if the master key and the salting key are both delivered by MIKEY and used in SRTP to derive the session keys, what is to value of the salt, when it is changed every time the master key is changed too? I thought the salt would provide randomness in the case of using the master key multiple times. What would be example offline attacks that leverage the absence of the salt? Regards Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Dec 17 17:30:23 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 RAA20311 for ; Fri, 17 Dec 2004 17:30:23 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A37508D990; Fri, 17 Dec 2004 17:30:24 -0500 (EST) 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 A63DF8D96E for ; Fri, 17 Dec 2004 17:30:22 -0500 (EST) Received: (qmail 5506 invoked by uid 3269); 17 Dec 2004 22:30:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5503 invoked from network); 17 Dec 2004 22:30:22 -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; 17 Dec 2004 22:30:22 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Dec 2004 15:37:31 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBHMUGo9003434; Fri, 17 Dec 2004 14:30:17 -0800 (PST) Received: from [192.168.0.10] (sjc-vpn5-818.cisco.com [10.21.91.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iBHMSn5V003771; Fri, 17 Dec 2004 14:28:49 -0800 In-Reply-To: <41C2AD96.4410.4E62E6C@localhost> References: <41C2AD96.4410.4E62E6C@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3A04B194-507B-11D9-8023-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] MIKEY Question Date: Fri, 17 Dec 2004 14:30:16 -0800 To: steffen.fries@siemens.com X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1103322529.747739"; x:"432200"; a:"rsa-sha1"; b:"nofws:1210"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"WlCd/yKW9uMgbAcnTOm7MvLAeHK2PVew8dtqp9hfuzEMwWSWpq4meNMvvtuue" "GNR6p0gcAEkFyyZD0/y14TvYoL4HS2Ndm3Q1e4Ny51Z/uVswNA0RhGwv8r5Lq" "pSXFSYnALyiinQ/GJye41YlXKb/GbHvD2MetRujSYVFhh1XEU="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] MIKEY Question"; c:"Date: Fri, 17 Dec 2004 14:30:16 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: "David A. McGrew" , 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 Steffen, On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: > Hi, > > I've got a question to the usage of the salt and master key (TGK) > delivered by MIKEY. Does MIKEY offer an option to update the > salting key alone by keeping the same TGK? I can't imagine why anyone would want to do that given the purpose of the salting key (see http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The question behind that is if the master key and the salting key > are both delivered by MIKEY and used in SRTP to derive the > session keys, what is to value of the salt, when it is changed > every time the master key is changed too? I thought the salt The purpose is to make a precomputation attack infeasible. > would provide randomness in the case of using the master key > multiple times. No, it does not do that. It's a public value. > What would be example offline attacks that > leverage the absence of the salt? Specific attacks on additive encryption in the case of RFC 3711. Mark > > Regards > Steffen > _______________________________________________ > 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 Mon Dec 20 02:51:37 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 CAA08269 for ; Mon, 20 Dec 2004 02:51:37 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F08538D77F; Mon, 20 Dec 2004 02:51:37 -0500 (EST) 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 148838D77B for ; Mon, 20 Dec 2004 02:51:36 -0500 (EST) Received: (qmail 72762 invoked by uid 3269); 20 Dec 2004 07:51:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72759 invoked from network); 20 Dec 2004 07:51:35 -0000 Received: from penguin.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 20 Dec 2004 07:51:35 -0000 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBK7oQlZ019705; Mon, 20 Dec 2004 08:51:32 +0100 (MET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 08:51:02 +0100 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 08:51:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] MIKEY Question Date: Mon, 20 Dec 2004 08:51:02 +0100 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB021111C7@esealmw104.eemea.ericsson.se> Thread-Topic: [MSEC] MIKEY Question Thread-Index: AcTkiBiaQplKkylDS0KrCKj5ltNjZgB3/0Qg From: "Fredrik Lindholm (KI/EAB)" To: X-OriginalArrivalTime: 20 Dec 2004 07:51:02.0508 (UTC) FILETIME=[A6F1FAC0:01C4E668] Cc: "David A. McGrew" , 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 Hi Steffen, MIKEY does not support the option to update the salting key alone. Regards, Fredrik =20 > On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: >=20 > > Hi, > > > > I've got a question to the usage of the salt and master key (TGK) > > delivered by MIKEY. Does MIKEY offer an option to update the > > salting key alone by keeping the same TGK? >=20 > I can't imagine why anyone would want to do that given the purpose of=20 > the salting key (see=20 > http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > > > The question behind that is if the master key and the salting key > > are both delivered by MIKEY and used in SRTP to derive the > > session keys, what is to value of the salt, when it is changed > > every time the master key is changed too? I thought the salt >=20 > The purpose is to make a precomputation attack infeasible. >=20 > > would provide randomness in the case of using the master key > > multiple times. >=20 > No, it does not do that. It's a public value. >=20 > > What would be example offline attacks that > > leverage the absence of the salt? >=20 > Specific attacks on additive encryption in the case of RFC 3711. >=20 > Mark > > > > Regards > > Steffen > > _______________________________________________ > > 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 >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Dec 20 10:24:06 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 KAA06388 for ; Mon, 20 Dec 2004 10:24:04 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8D0308CC3C; Mon, 20 Dec 2004 10:24:03 -0500 (EST) 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 3F02C8C7C2 for ; Mon, 20 Dec 2004 10:24:02 -0500 (EST) Received: (qmail 48004 invoked by uid 3269); 20 Dec 2004 15:24:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48001 invoked from network); 20 Dec 2004 15:24:01 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 20 Dec 2004 15:24:01 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBKFNvtr001052; Mon, 20 Dec 2004 16:23:57 +0100 Received: from MCHN070C (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iBKFNvmC014716; Mon, 20 Dec 2004 16:23:57 +0100 From: "Steffen Fries" Organization: Siemens AG To: Mark Baugher Date: Mon, 20 Dec 2004 16:23:58 +0100 MIME-Version: 1.0 Subject: Re: [MSEC] MIKEY Question Message-ID: <41C6FC9E.29932.FD10F7A@localhost> Priority: normal In-reply-to: <3A04B194-507B-11D9-8023-000A95DC10F2@cisco.com> References: <41C2AD96.4410.4E62E6C@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: "David A. McGrew" , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Mark, thank you for the information, I made some inline comments. > Steffen, > > On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: > > > Hi, > > > > I've got a question to the usage of the salt and master key (TGK) > > delivered by MIKEY. Does MIKEY offer an option to update the salting > > key alone by keeping the same TGK? > > I can't imagine why anyone would want to do that given the purpose of > the salting key (see > http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The > question behind that is if the master key and the salting key > are > both delivered by MIKEY and used in SRTP to derive the > session keys, > what is to value of the salt, when it is changed > every time the > master key is changed too? I thought the salt > > The purpose is to make a precomputation attack infeasible. stf: aggreed, but this relates to the data encrypted and eavesdropped on the network, which would be SRTP data. Since SRTP also provides the option to use a salt a similar question arises here. (Aehm, we are switching the topic from MIKEY to SRTP now ;-)) Isn't in SRTP a "salting effect" already provided through the IV? > > > would provide randomness in the case of using the master key > > multiple times. > > No, it does not do that. It's a public value. stf: If I understand it right it may be public after usage. Regards Steffen > > > What would be example offline attacks that > > leverage the absence of the salt? > > Specific attacks on additive encryption in the case of RFC 3711. > > Mark > > > > Regards > > Steffen > > _______________________________________________ > > 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 Mon Dec 20 11:31: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 LAA14386 for ; Mon, 20 Dec 2004 11:31:39 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 42B5B8C7EE; Mon, 20 Dec 2004 11:31:39 -0500 (EST) 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 2E9A68C0B5 for ; Mon, 20 Dec 2004 11:31:38 -0500 (EST) Received: (qmail 59344 invoked by uid 3269); 20 Dec 2004 16:31:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59340 invoked from network); 20 Dec 2004 16:31: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; 20 Dec 2004 16:31:38 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Dec 2004 09:39:20 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBKGVTdP016686; Mon, 20 Dec 2004 08:31:30 -0800 (PST) Received: from [192.168.0.10] (sjc-vpn6-768.cisco.com [10.21.123.0]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iBKGTtZM017586; Mon, 20 Dec 2004 08:29:55 -0800 In-Reply-To: <41C6FC9E.29932.FD10F7A@localhost> References: <41C2AD96.4410.4E62E6C@localhost> <41C6FC9E.29932.FD10F7A@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9B1E198A-52A4-11D9-8023-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] MIKEY Question Date: Mon, 20 Dec 2004 08:31:31 -0800 To: steffen.fries@siemens.com X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1103560195.505306"; x:"432200"; a:"rsa-sha1"; b:"nofws:2311"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"KFID27FJzbs+JwpIZIpO/bFLGrCZYpMfHCEVHX90iv1lDuab/vJpVO2Aqf/t4" "q6tOdU4x439JN6rzQeof068HHGjRUiBJNqj/roWEvUQZz2Kzco/no40KTR4gZ" "kGwFpWKARh7hbJ+1qL+ftuZsMURoMvrx+jVCx4oeOlFVVeaZ4="; c:"From: Mark Baugher "; c:"Subject: Re: [MSEC] MIKEY Question"; c:"Date: Mon, 20 Dec 2004 08:31:31 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Cc: "David A. McGrew" , 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 Steffen, On Dec 20, 2004, at 7:23 AM, Steffen Fries wrote: > Hi Mark, > > thank you for the information, I made some inline comments. > >> Steffen, >> >> On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: >> >>> Hi, >>> >>> I've got a question to the usage of the salt and master key (TGK) >>> delivered by MIKEY. Does MIKEY offer an option to update the salting >>> key alone by keeping the same TGK? >> >> I can't imagine why anyone would want to do that given the purpose of >> the salting key (see >> http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The >> question behind that is if the master key and the salting key > are >> both delivered by MIKEY and used in SRTP to derive the > session keys, >> what is to value of the salt, when it is changed > every time the >> master key is changed too? I thought the salt >> >> The purpose is to make a precomputation attack infeasible. > stf: aggreed, but this relates to the data encrypted and > eavesdropped on the network, which would be SRTP data. Since > SRTP also provides the option to use a salt a similar question > arises here. (Aehm, we are switching the topic from MIKEY to > SRTP now ;-)) Isn't in SRTP a "salting effect" already provided > through the IV? David and Mats decided to exor the salt in the IV that generates the keystream and that's how RFC 3711 does it. So the salting effect is provided in the IV through the salt. Conceptually, the salt starts the counter at a random offset in the counter space. > >> >>> would provide randomness in the case of using the master key >>> multiple times. >> >> No, it does not do that. It's a public value. > stf: If I understand it right it may be public after usage. Yes, my understanding is that the salt is not known until the SRTP session commences. David is copied on this note and can weigh on this. Cheers, Mark > > Regards > Steffen > >> >>> What would be example offline attacks that >>> leverage the absence of the salt? >> >> Specific attacks on additive encryption in the case of RFC 3711. >> >> Mark >>> >>> Regards >>> Steffen >>> _______________________________________________ >>> 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 Mon Dec 20 14:16: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 OAA24213 for ; Mon, 20 Dec 2004 14:16:00 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 35EDD8D481; Mon, 20 Dec 2004 14:16:01 -0500 (EST) 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 35C4C8D142 for ; Mon, 20 Dec 2004 14:16:00 -0500 (EST) Received: (qmail 86709 invoked by uid 3269); 20 Dec 2004 19:16:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86706 invoked from network); 20 Dec 2004 19:15:59 -0000 Received: from albatross.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 20 Dec 2004 19:15:59 -0000 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBKJFuvH025582; Mon, 20 Dec 2004 20:15:57 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 20:15:55 +0100 Received: from ericsson.com ([147.214.97.151]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 20:15:55 +0100 Message-ID: <41C724EA.8070700@ericsson.com> Date: Mon, 20 Dec 2004 20:15:54 +0100 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MSEC] MIKEY Question References: <9B1E198A-52A4-11D9-8023-000A95DC10F2@cisco.com> In-Reply-To: <9B1E198A-52A4-11D9-8023-000A95DC10F2@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2004 19:15:55.0527 (UTC) FILETIME=[544B1170:01C4E6C8] Cc: "David A. McGrew" , steffen.fries@siemens.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, The motivation for using salt in MIKEY is similar, but not entirely identical, to the reason we have salt in SRTP. In both cases, the perhaps most important reason is to avoid pre-computation attacks. In SRTP we here mean an attack against the confidentiality, in MIKEY it would be an attack against the key derivation. So, a pre-computation attack against SRTP encryption would "only" disclose the session key for confidentiality. A pre-computation attack against MIKEY would be worse, since it would be an attack against the TGK, hence *all* keys (TEKs) derived from that TGK would be disclosed. In fact, if you use MIKEY with SRTP, there are three "levels" of salt. One on the MIKEY level, one in the SRTP local key derivation, and one in the SRTP cipher IV, all of them protecting against attacks on the respective "level". Cheers /Mats Mark Baugher wrote: > Steffen, > > On Dec 20, 2004, at 7:23 AM, Steffen Fries wrote: > > > Hi Mark, > > > > thank you for the information, I made some inline comments. > > > >> Steffen, > >> > >> On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: > >> > >>> Hi, > >>> > >>> I've got a question to the usage of the salt and master key (TGK) > >>> delivered by MIKEY. Does MIKEY offer an option to update the salting > >>> key alone by keeping the same TGK? > >> > >> I can't imagine why anyone would want to do that given the purpose of > >> the salting key (see > >> http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The > >> question behind that is if the master key and the salting key > are > >> both delivered by MIKEY and used in SRTP to derive the > session keys, > >> what is to value of the salt, when it is changed > every time the > >> master key is changed too? I thought the salt > >> > >> The purpose is to make a precomputation attack infeasible. > > stf: aggreed, but this relates to the data encrypted and > > eavesdropped on the network, which would be SRTP data. Since > > SRTP also provides the option to use a salt a similar question > > arises here. (Aehm, we are switching the topic from MIKEY to > > SRTP now ;-)) Isn't in SRTP a "salting effect" already provided > > through the IV? > > David and Mats decided to exor the salt in the IV that generates the > keystream and that's how RFC 3711 does it. So the salting effect is > provided in the IV through the salt. Conceptually, the salt starts the > counter at a random offset in the counter space. > > > >> > >>> would provide randomness in the case of using the master key > >>> multiple times. > >> > >> No, it does not do that. It's a public value. > > stf: If I understand it right it may be public after usage. > > Yes, my understanding is that the salt is not known until the SRTP > session commences. David is copied on this note and can weigh on this. > > Cheers, Mark > > > > Regards > > Steffen > > > >> > >>> What would be example offline attacks that > >>> leverage the absence of the salt? > >> > >> Specific attacks on additive encryption in the case of RFC 3711. > >> > >> Mark > >>> > >>> Regards > >>> Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Dec 21 07:00: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 HAA29039 for ; Tue, 21 Dec 2004 07:00:52 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 40D8E8CCC5; Tue, 21 Dec 2004 07:00:50 -0500 (EST) 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 5DD818C4AB for ; Tue, 21 Dec 2004 07:00:48 -0500 (EST) Received: (qmail 82424 invoked by uid 3269); 21 Dec 2004 12:00:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82421 invoked from network); 21 Dec 2004 12:00:48 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 21 Dec 2004 12:00:48 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBLC0gtr011239; Tue, 21 Dec 2004 13:00:42 +0100 Received: from MCHN070C (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id iBLC0gqs024503; Tue, 21 Dec 2004 13:00:42 +0100 From: "Steffen Fries" Organization: Siemens AG To: Mark Baugher , "=?ISO-8859-1?Q?Mats_N=E4slund?=" Date: Tue, 21 Dec 2004 13:00:42 +0100 MIME-Version: 1.0 Subject: Re: [MSEC] MIKEY Question Message-ID: <41C81E7A.8360.1448F9@localhost> Priority: normal In-reply-to: <41C724EA.8070700@ericsson.com> References: <9B1E198A-52A4-11D9-8023-000A95DC10F2@cisco.com> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: "David A. McGrew" , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Maets, thanks for the explanation. What you wrote is is actually also my view. The only thing is that I would like to understand the attack better. The attack assumes that somebody pre-computes packets, which he may compare afterwards during the communication with eavesdropped packets. I made some further inline comments, which show my point. > The motivation for using salt in MIKEY is similar, but not > entirely identical, to the reason we have salt in SRTP. > > In both cases, the perhaps most important reason is to avoid > pre-computation attacks. In SRTP we here mean an attack against the > confidentiality, in MIKEY it would be an attack against the key > derivation. stf: aggreed. Just for my understanding, in case of MIKEY the TGK and the salt is delivered as part of the payload. This is something one could eavesdrop. But here the pre-computation attack may not work as the MIKEY container supplies the TGK and the salt. The MIKEY container is protected by other means (either (public key) encryption or DH kee agreement) > So, a pre-computation attack against SRTP encryption would "only" > disclose the session key for confidentiality. > > A pre-computation attack against MIKEY would be worse, since it would > be an attack against the TGK, hence *all* keys (TEKs) derived from > that TGK would be disclosed. stf: aggreed > > In fact, if you use MIKEY with SRTP, there are three "levels" of salt. > One on the MIKEY level, one in the SRTP local key derivation, and one > in the SRTP cipher IV, all of them protecting against attacks on the > respective "level". stf: Yes, I aggree to the key derivation argument, but isn't the IV itself not "salt" enough as it is build depending on parameters, which belong to the packet (SSRC, packet index) and which may be hard to predict? Regards Steffen > > Cheers > > /Mats > > Mark Baugher wrote: > > Steffen, > > > > On Dec 20, 2004, at 7:23 AM, Steffen Fries wrote: > > > > > Hi Mark, > > > > > > thank you for the information, I made some inline comments. > > > > > >> Steffen, > > >> > > >> On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: > > >> > > >>> Hi, > > >>> > > >>> I've got a question to the usage of the salt and master key > > >>> (TGK) delivered by MIKEY. Does MIKEY offer an option to update > > >>> the salting key alone by keeping the same TGK? > > >> > > >> I can't imagine why anyone would want to do that given the > > >> purpose of the salting key (see > > >> http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The > > >> question behind that is if the master key and the salting key > > > >> are both delivered by MIKEY and used in SRTP to derive the > > > >> session keys, what is to value of the salt, when it is changed > > > >> every time the master key is changed too? I thought the salt > > >> > > >> The purpose is to make a precomputation attack infeasible. > > > stf: aggreed, but this relates to the data encrypted and > > > eavesdropped on the network, which would be SRTP data. Since SRTP > > > also provides the option to use a salt a similar question arises > > > here. (Aehm, we are switching the topic from MIKEY to SRTP now > > > ;-)) Isn't in SRTP a "salting effect" already provided through > > > the IV? > > > > David and Mats decided to exor the salt in the IV that generates the > > keystream and that's how RFC 3711 does it. So the salting effect is > > provided in the IV through the salt. Conceptually, the salt starts > > the counter at a random offset in the counter space. > > > > > >> > > >>> would provide randomness in the case of using the master key > > >>> multiple times. > > >> > > >> No, it does not do that. It's a public value. > > > stf: If I understand it right it may be public after usage. > > > > Yes, my understanding is that the salt is not known until the SRTP > > session commences. David is copied on this note and can weigh on > > this. > > > > Cheers, Mark > > > > > > Regards > > > Steffen > > > > > >> > > >>> What would be example offline attacks that > > >>> leverage the absence of the salt? > > >> > > >> Specific attacks on additive encryption in the case of RFC 3711. > > >> > > >> Mark > > >>> > > >>> Regards > > >>> Steffen > ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Dec 21 07:50:40 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 HAA04109 for ; Tue, 21 Dec 2004 07:50:40 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 144E48C992; Tue, 21 Dec 2004 07:50:41 -0500 (EST) 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 0E8838C970 for ; Tue, 21 Dec 2004 07:50:39 -0500 (EST) Received: (qmail 89255 invoked by uid 3269); 21 Dec 2004 12:50:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89252 invoked from network); 21 Dec 2004 12:50:38 -0000 Received: from albatross.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 21 Dec 2004 12:50:38 -0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iBLCobvD016818 for ; Tue, 21 Dec 2004 13:50:37 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Dec 2004 13:50:36 +0100 Received: from ericsson.com (research-64de67.ki.sw.ericsson.se [147.214.118.190]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAPCNK2C; Tue, 21 Dec 2004 13:50:36 +0100 Message-ID: <41C81C1C.1050706@ericsson.com> Date: Tue, 21 Dec 2004 13:50:36 +0100 X-Sybari-Trust: 6c3ab0de 96d33411 ac6a41d7 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: steffen.fries@siemens.com Subject: Re: [MSEC] MIKEY Question References: <9B1E198A-52A4-11D9-8023-000A95DC10F2@cisco.com> <41C81E7A.8360.1448F9@localhost> In-Reply-To: <41C81E7A.8360.1448F9@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2004 12:50:36.0271 (UTC) FILETIME=[AA8E4FF0:01C4E75B] Cc: "David A. McGrew" , 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 Hello Steffen, Steffen Fries wrote: > thanks for the explanation. > > What you wrote is is actually also my view. The only thing is > that I would like to understand the attack better. The attack > assumes that somebody pre-computes packets, which he may compare > afterwards during the communication with eavesdropped packets. I > made some further inline comments, which show my point. Here is a sketch on how a pre-comp attack on MIKEYs key derivation (KDF) could work (assuming no salt/RAND is used): 1. Generate randomly and independently 2^t TGKs. 2. Run each TGK through the KDF to obtain, say, an integrity key, k = KDF(TGK). (Assumption: somewhere in the session that follows there will be some predictable message, m, occurring that is to be integrity protected.) 3. Integrity protect said predictable message with each candidate key, k, producing MAC tag T_m(k) = T_m(KDF(TGK)). 4. Store all (T_m(KDF(TGK)), TGK) pairs indexed by T_m(k) value. This concludes the off-line precomputation phase, which is done once and for all. In the on-line phase, we observe about 2^s "sessions", we assume all (or almost all) contain the predictable message m. If in one of these, we see the tag T_m(k) occurring, there's a reasonable chance (depending on the size of the tag) that we have the right TGK value in our database. Roughly, if s + t > size(TGK), we can hope with some reasonable prob. that we have the right TGK, from which we can then deduce *all* derived keys. E.g. if size(TGK) = 128, s = t = 64 would work. There are perhaps more clever attacks, the one above is a bit naive but I think it shows the principle. In practice, other things may be in place to protect against this attack, but it *could* be this simple, and we should take countermeasures using a salt/RAND, since it really doesn't cost much. > > >>The motivation for using salt in MIKEY is similar, but not >>entirely identical, to the reason we have salt in SRTP. >> >>In both cases, the perhaps most important reason is to avoid >>pre-computation attacks. In SRTP we here mean an attack against the >>confidentiality, in MIKEY it would be an attack against the key >>derivation. > > stf: aggreed. Just for my understanding, in case of MIKEY the > TGK and the salt is delivered as part of the payload. This is > something one could eavesdrop. But here the pre-computation > attack may not work as the MIKEY container supplies the TGK and > the salt. The MIKEY container is protected by other means > (either (public key) encryption or DH kee agreement) The pre-computation attack breaks down even if the salt was in the clear, since the salt would need to be known already in the off-line phase. Of course, you could "loop" over possible salts too, but if size(salt) >= size(TGK), the attack has complexity at least 2^size(TGK), and it becomes a "trivial" attack. >>So, a pre-computation attack against SRTP encryption would "only" >>disclose the session key for confidentiality. >> >>A pre-computation attack against MIKEY would be worse, since it would >>be an attack against the TGK, hence *all* keys (TEKs) derived from >>that TGK would be disclosed. > > stf: aggreed > >>In fact, if you use MIKEY with SRTP, there are three "levels" of salt. >>One on the MIKEY level, one in the SRTP local key derivation, and one >>in the SRTP cipher IV, all of them protecting against attacks on the >>respective "level". > > stf: Yes, I aggree to the key derivation argument, but isn't the > IV itself not "salt" enough as it is build depending on > parameters, which belong to the packet (SSRC, packet index) and > which may be hard to predict? In the case that MIKEY is used with SRTP, yes, there are requirements in the RTP spec on SSRC and sequence number starting from "random" values. However, we chose not to trust these quantities to provide "cryptographic quality" randomness, and so we added out own salt, though in practice you are right, the SSRC etc would serve similar purposes assuming they are unpredictable enough. Cheers /Mats >>Mark Baugher wrote: >> >>>Steffen, >>> >>>On Dec 20, 2004, at 7:23 AM, Steffen Fries wrote: >>> >>> > Hi Mark, >>> > >>> > thank you for the information, I made some inline comments. >>> > >>> >> Steffen, >>> >> >>> >> On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> I've got a question to the usage of the salt and master key >>> >>> (TGK) delivered by MIKEY. Does MIKEY offer an option to update >>> >>> the salting key alone by keeping the same TGK? >>> >> >>> >> I can't imagine why anyone would want to do that given the >>> >> purpose of the salting key (see >>> >> http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The >>> >> question behind that is if the master key and the salting key > >>> >> are both delivered by MIKEY and used in SRTP to derive the > >>> >> session keys, what is to value of the salt, when it is changed > >>> >> every time the master key is changed too? I thought the salt >>> >> >>> >> The purpose is to make a precomputation attack infeasible. >>> > stf: aggreed, but this relates to the data encrypted and >>> > eavesdropped on the network, which would be SRTP data. Since SRTP >>> > also provides the option to use a salt a similar question arises >>> > here. (Aehm, we are switching the topic from MIKEY to SRTP now >>> > ;-)) Isn't in SRTP a "salting effect" already provided through >>> > the IV? >>> >>>David and Mats decided to exor the salt in the IV that generates the >>>keystream and that's how RFC 3711 does it. So the salting effect is >>>provided in the IV through the salt. Conceptually, the salt starts >>>the counter at a random offset in the counter space. >>> > >>> >> >>> >>> would provide randomness in the case of using the master key >>> >>> multiple times. >>> >> >>> >> No, it does not do that. It's a public value. >>> > stf: If I understand it right it may be public after usage. >>> >>>Yes, my understanding is that the salt is not known until the SRTP >>>session commences. David is copied on this note and can weigh on >>>this. >>> >>>Cheers, Mark >>> > >>> > Regards >>> > Steffen >>> > >>> >> >>> >>> What would be example offline attacks that >>> >>> leverage the absence of the salt? >>> >> >>> >> Specific attacks on additive encryption in the case of RFC 3711. >>> >> >>> >> Mark >>> >>> >>> >>> Regards >>> >>> Steffen >> _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Dec 22 03:22: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 DAA00573 for ; Wed, 22 Dec 2004 03:22:04 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6973D8D0F6; Wed, 22 Dec 2004 03:22:05 -0500 (EST) 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 E804D8D0EB for ; Wed, 22 Dec 2004 03:22:03 -0500 (EST) Received: (qmail 21244 invoked by uid 3269); 22 Dec 2004 08:22:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21239 invoked from network); 22 Dec 2004 08:22:03 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 22 Dec 2004 08:22:03 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iBM8LxVi005466; Wed, 22 Dec 2004 09:21:59 +0100 Received: from MCHN070C (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iBM8LxmC008828; Wed, 22 Dec 2004 09:21:59 +0100 From: "Steffen Fries" Organization: Siemens AG To: "=?ISO-8859-1?Q?Mats_N=E4slund?=" Date: Wed, 22 Dec 2004 09:21:55 +0100 MIME-Version: 1.0 Subject: Re: [MSEC] MIKEY Question Message-ID: <41C93CB3.23671.4725A69@localhost> Priority: normal In-reply-to: <41C81C1C.1050706@ericsson.com> References: <41C81E7A.8360.1448F9@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: "David A. McGrew" , Mark Baugher , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steffen.fries@siemens.com 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 Maets, I now see the reasonning for salting. I made some inline comments. --- snipp --- > Here is a sketch on how a pre-comp attack on MIKEYs key derivation > (KDF) could work (assuming no salt/RAND is used): > > 1. Generate randomly and independently 2^t TGKs. > > 2. Run each TGK through the KDF to obtain, say, an integrity key, > k = KDF(TGK). > > (Assumption: somewhere in the session that follows there will be > some predictable message, m, occurring that is to be integrity > protected.) > > 3. Integrity protect said predictable message with each candidate key, > k, producing MAC tag T_m(k) = T_m(KDF(TGK)). > > 4. Store all (T_m(KDF(TGK)), TGK) pairs indexed by T_m(k) value. > > > This concludes the off-line precomputation phase, which is done once > and for all. > > In the on-line phase, we observe about 2^s "sessions", we assume all > (or almost all) contain the predictable message m. If in one of these, > we see the tag T_m(k) occurring, there's a reasonable chance > (depending on the size of the tag) that we have the right TGK value in > our database. stf: Your explanation of the attack reflects my assumptions. Not using the salt by the security protocol utilizing MIKEY would enable these attacks. --- snipp --- > > The pre-computation attack breaks down even if the salt was in the > clear, since the salt would need to be known already in the off-line > phase. Of course, you could "loop" over possible salts too, but if > size(salt) >= size(TGK), the attack has complexity at least > 2^size(TGK), and it becomes a "trivial" attack. stf: okay > --- snipp --- > In the case that MIKEY is used with SRTP, yes, there are requirements > in the RTP spec on SSRC and sequence number starting from "random" > values. However, we chose not to trust these quantities to provide > "cryptographic quality" randomness, and so we added out own salt, > though in practice you are right, the SSRC etc would serve similar > purposes assuming they are unpredictable enough. stf: okay, I now understand the reasoning. Maets, thanks for your detailed answer. Have a Merry Christmas and a Happy New Year! Ciao Steffen > > Cheers > > /Mats > > >>Mark Baugher wrote: > >> > >>>Steffen, > >>> > >>>On Dec 20, 2004, at 7:23 AM, Steffen Fries wrote: > >>> > >>> > Hi Mark, > >>> > > >>> > thank you for the information, I made some inline comments. > >>> > > >>> >> Steffen, > >>> >> > >>> >> On Dec 17, 2004, at 12:57 AM, Steffen Fries wrote: > >>> >> > >>> >>> Hi, > >>> >>> > >>> >>> I've got a question to the usage of the salt and master key > >>> >>> (TGK) delivered by MIKEY. Does MIKEY offer an option to update > >>> >>> the salting key alone by keeping the same TGK? > >>> >> > >>> >> I can't imagine why anyone would want to do that given the > >>> >> purpose of the salting key (see > >>> >> http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The > >>> >> question behind that is if the master key and the salting key > > >>> >> are both delivered by MIKEY and used in SRTP to derive the > > >>> >> session keys, what is to value of the salt, when it is changed > >>> >> > every time the master key is changed too? I thought the salt > >>> >> > >>> >> The purpose is to make a precomputation attack infeasible. > >>> > stf: aggreed, but this relates to the data encrypted and > >>> > eavesdropped on the network, which would be SRTP data. Since > >>> > SRTP also provides the option to use a salt a similar question > >>> > arises here. (Aehm, we are switching the topic from MIKEY to > >>> > SRTP now ;-)) Isn't in SRTP a "salting effect" already provided > >>> > through the IV? > >>> > >>>David and Mats decided to exor the salt in the IV that generates > >>>the keystream and that's how RFC 3711 does it. So the salting > >>>effect is provided in the IV through the salt. Conceptually, the > >>>salt starts the counter at a random offset in the counter space. > >>> > > >>> >> > >>> >>> would provide randomness in the case of using the master key > >>> >>> multiple times. > >>> >> > >>> >> No, it does not do that. It's a public value. > >>> > stf: If I understand it right it may be public after usage. > >>> > >>>Yes, my understanding is that the salt is not known until the SRTP > >>>session commences. David is copied on this note and can weigh on > >>>this. > >>> > >>>Cheers, Mark > >>> > > >>> > Regards > >>> > Steffen > >>> > > >>> >> > >>> >>> What would be example offline attacks that > >>> >>> leverage the absence of the salt? > >>> >> > >>> >> Specific attacks on additive encryption in the case of RFC > >>> >> 3711. > >>> >> > >>> >> Mark > >>> >>> > >>> >>> Regards > >>> >>> Steffen > >> > > ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec