Subject: RE: [MSEC] RE: MUST/MAY discard unverifiable(draft-ietf-msec-srtp-tesla-02.txt)

From: <[email-masked]>
Date: Wed, 1 Dec 2004 11:45:52 -0500

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: [email-masked]
> [mailto:[email-masked]]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;
> [email-masked]
> 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:[email-masked]]
> >Sent: den 29 november 2004 00:00
> >To: Mark Baugher; Elisabetta Carrara (KI/EAB)
> >Cc: [email-masked]; [email-masked]; 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, <[email-masked]>      Networks Research 
> >Centre, BT Research
> >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   
> >+44 1473 645196 
> >
> >
> _______________________________________________
> msec mailing list
> [email-masked]
> http://six.pairlist.net/mailman/listinfo/msec
> 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 03 Dec 2004 17:38:54 +0000

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

> > >uncertainty. But we have to remember security must be balanced

____________________________________________________________________________
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