Subject: RE: [NSIS] Security Threats for NSIS : Insecure Parameter Exchang e and Negot iation

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 15 Apr 2004 16:14:06 +0100

ok, i think we agree: the rule "if you want to negotiate security,
don't allow include any mechanism which can be attacked in real
time as an option (regardless of who you think you are negotiating 
with)" is an example of what i would call a static policy.

then I think there are two questions:

1. i think the sentence "Hence, without binding the 
   negotiation process to the legitimate parties and protecting it, an 
   NSIS protocol might be only as secure as the weakest mechanism 
   provided (e.g., weak authentication), and the benefits of defining 
   configuration parameters and a negotiation protocol are lost."

is possibly misleading. isn't it the point that the "NSIS protocol" *is
always* "only as secure as the weakest mechanism provided", regardless
of how the negotiation is wrapped up.

2. although the document is (I think rightly) steering clear of 
suggesting what the solutions to address the threat should be,
i think a reference to something like sipsec-agree is still helpful,
because it explains a concrete example of the threat in much more 
detail (as well as providing a solution). One could add something
like "For example, this threat arises in the negotiation of security
mechanisms for SIP; a discussion of the threat and a solution are 
provided in [3329]."

r.

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]]
> Sent: Thursday, April 15, 2004 14:45
> To: [email-masked]'
> Subject: [NSIS] Security Threats for NSIS : Insecure 
> Parameter Exchange
> and Negot iation
> 
> 
> hi all, 
> 
> > 3.4 Insecure Parameter Exchange and Negotiation
> 
> > I think this threat is very important to consider. But is there
> > any way to handle it except in the context of a security protocol
> > (unless you rely on static policies)? You can always mount a 
> > downgrading attack on the authentication process itself, at 
> > which point you are finished.
> 
> yes. typically one has to repeat the parameters again after a security
> association has been established. 
> if the weakest mechanism is resistant against a real-time 
> attack (i.e., a
> cryptomechanism which can be broken in realtime before the 
> negotiation is
> completed) then the modification will be discovered. 
> 
> you can find an example of this in: 
> http://www.ietf.org/rfc/rfc3329.txt
> 
> ciao
> hannes
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 17 Apr 2004 14:38:04 +0200

hi robert, 
 
> ok, i think we agree: the rule "if you want to negotiate 
> security, don't allow include any mechanism which can be 
> attacked in real time as an option (regardless of who you 
> think you are negotiating with)" is an example of what i 
> would call a static policy.
> 
> always* "only as secure as the weakest mechanism provided", 
> regardless of how the negotiation is wrapped up.
you can even provide a negotiation mechanism which is insecure at all or 
you could provide no mechanisms for negotiating anything or 
you move the negotiation into a separate protocol (e.g., you mandate ikev2
and ikev2 provides mechanisms for negotiation).

what about changing the above sentence to:

"
Hence, without binding the negotiation process to the legitimate parties and
protecting it, the threat of a downgrading attack might be introduced. This
might cause weaker security mechanisms or inadequate parameters to be
selected.
"

> 
> 2. although the document is (I think rightly) steering clear 
> of suggesting what the solutions to address the threat should 
> be, i think a reference to something like sipsec-agree is 
> still helpful, because it explains a concrete example of the 
> threat in much more detail (as well as providing a solution). 

i also thought so some time ago when i included more specific examples. that
was before i had to remove all those solution specific aspects again, since
people asked me todo so. 

if there are no objections that i will add a reference and mention that this
is an example. 

> One could add something like "For example, this threat arises 
> in the negotiation of security mechanisms for SIP; a 
> discussion of the threat and a solution are provided in [3329]."

i personally have no objections against including it. 

ciao
hannes

> -- 
> Visit our website at www.roke.co.uk
> 
> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
> Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments is
> confidential to
> Roke Manor Research Ltd and must not be passed to any third party
> without
> permission. This communication is for information only and shall not
> create or
> change any contractual relationship.
>