Subject: RE: [MSEC] MIKEY D-H + SIP layer signature

From: Fries Steffen <[email-masked]>
Date: Wed, 30 Mar 2005 08:03:26 +0200

Hi Mark,

the pre-shared case may be usefule in cases, were a shared secret is either
already in place or distributed via other mechanisms. 
For instance in enterprise environments one may think of a pre-shared
secret, which is provided through a central server depending on the
registration of clients (could be done by the registering server), either by
the multimedia protocol itself or through additional protocols. This
approach does not provide true end-to-end security, as the central server
provides the key applied to MIKEY, but may be sufficient in certain
environments. This may be advantageous in situations, in which the
multimedia protocols are used without confidentiality protection by their
own (does not apply to DH, but to the pre-shared based encryption described
in MIKEY). 
An example for pre-shared secret provision through a central entity is
described in the direct routed call with gatekeeper model in H.323. In a
nutshell, through the call admission, the gatekeeper provides encrypted
token for the caller, which include a shared secret, which is call related.
The caller decrypts the token targeted to him and includes the other token
in his setup message to the callee. The encryption is done with a key
derived from the key used during registration. 

Outside an enterprise such a solution may not be easy deployable, as all
involved parties would have to trust some central entity to provide the
pre-shared secret in a secure way. Here, asymmetric methods may be more
useful.    

Regards
	Steffen

> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]] 
> Sent: Tuesday, March 29, 2005 5:07 PM
> To: Fries Steffen
> Cc: David A. McGrew; Mats Näslund; [email-masked]; Johan 
> Bilien; [email-masked]
> Subject: Re: [MSEC] MIKEY D-H + SIP layer signature
> 
> hi Steffen,
>     How do you envision the pre-shared key arrangement to be 
> used in practice?  How would thousands of enterprise 
> customers' phones be configured to use a pre-shared secret 
> for secure telephony?  How do you envision this being used 
> outside the enterprise?
> 
> Mark
> On Mar 22, 2005, at 11:51 PM, Steffen Fries wrote:
> 
> > Hi Johan,
> >
> > additionally to the points from Mats, there is a draft available, 
> > which is currently in IESG review, which provides an extension to 
> > MIKEY , were the DH is protected using a pre-shared key 
> > (draft-ietf-msec-mikey-dhhmac-09.txt). Here basically the MIKEY 
> > message is integrity protected using HMAC-SHA1 and the 
> pre-shared key. 
> > If you are looking for a solution which is not consuming to much 
> > performance (compared to tweo digital
> > signatures) this might be interesting for you.
> >
> > Regards
> > 	Steffen
> >
> >
> > Date sent:      	Tue, 22 Mar 2005 18:26:12 +0100
> > From:           	Mats Näslund <[email-masked]>
> > To:             	Johan Bilien <[email-masked]>
> > Subject:        	Re: [MSEC] MIKEY D-H + SIP layer signature
> > Copies to:      	[email-masked]
> >
> >> Hi Johan,
> >>
> >> Johan Bilien wrote:
> >>
> >>> On Mon, Mar 21, 2005, Mats Näslund wrote:
> >>>> We discussed your proposal among the MIKEY authors, and 
> we have the 
> >>>> following comments.
> >>>
> >>> Thanks for your answer.
> >>>
> >>>>>  . by using S/MIME or another mechanism (Identity: 
> header...)  one 
> >>>>> can
> >>>>>    protect the whole SDP. This "glues" the MIKEY message to
> >>>>>    that SDP (the MIKEY message cannot be picked up from an
> >>>>>    INVITE and used in another one). It also removes the
> >>>>>    possibility of a downgrade
> >>>>
> >>>>
> >>>> Yes, but such an attack would as far as we see "only" have DoS 
> >>>> effects since different keys would be created at 
> >>>> Initiator/Responder sides.
> >>>
> >>> Yes, but that means that you cannot rely on the MIKEY message to 
> >>> provide authentication of the SIP message. If you need such an 
> >>> authentication
> >>
> >> Indeed. It is outside the scope of MIKEY to protect 
> non-MIKEY things. 
> >> Conversely, MIKEY should not have to trust that something 
> else takes 
> >> cares of MIKEY's own security.
> >>
> >>> (which you probably want if you care about security enough to use 
> >>> MIKEY
> >>> + SRTP), then you need an authentication at the SIP 
> layer, and end 
> >>> + up
> >>> having two digital signatures (and possibly two ways of carrying 
> >>> Id/Certificates, which can be the source of interoperability 
> >>> problems).
> >>
> >> First, one should not mix-up the need for end-to-end protection of 
> >> the media with the required security for the signaling. While 
> >> end-to-end protection is often desired for the media, end-to-end 
> >> protection of signaling may not always be possible (as SIP 
> ALGs may 
> >> need to modify messages for NAT traversal etc). Hop-by-hop 
> protection 
> >> of SIP using TLS or IPsec will be one solution that we 
> will see. This 
> >> is why we have not made any assumptions on the SIP signaling (more 
> >> than that it is reliable). In other words, MIKEY is 
> intended to be an 
> >> e2e mechanism, but SIP itself may not always be.
> >>
> >> Secondly, you seem to want to use D-H, which is a really heavy 
> >> mechanism, but at the same time the application you have in mind 
> >> seems to have performance trouble with two signatures. Of 
> course, D-H
> >> + 2 signatures is more expensive than D-H + one signature, but the
> >> difference is not extreme in most cases, and there are 
> other "modes"
> >> in MIKEY aimed exactly at constrained applications.
> >>
> >> We do not see why there would be interop problems: MIKEY specifies 
> >> how MIKEY is secured, the SIP security (whatever you use) should 
> >> similarly be well-defined. By creating a dependence 
> between MIKEY and 
> >> the transport mechanism that carries MIKEY, it could just 
> as well be 
> >> that interop problems are *created*.
> >>
> >>
> >>>
> >>>>>    attack, where someone would replace the SAVP profile with a
> >>>>>    usual RTP, and remove the MIKEY message. Of courses
> >>>>>    protecting the SDP has advantages independant of MIKEY, such
> >>>>>    as preventing the change of the c: field.
> >>>>
> >>>>
> >>>> The same is possible even with signature at the SIP level: just 
> >>>> peel off the signature part, delete the MIKEY line, and 
> change SAVP 
> >>>> to AVP.
> >>>
> >>> Agreed.
> >>>
> >>>>> Of course one can use the SIP layer signature on top of 
> the signed 
> >>>>> MIKEY message, but that is a waste of resource, the 
> MIKEY message 
> >>>>> being signed twice. So I think being able to create 
> unsigned D-H 
> >>>>> MIKEY messages would be a good thing.
> >>>>
> >>>> Note though that at the same time, we increase the 
> possibility of 
> >>>> (perhaps by misstake) using MIKEY-DH without 
> authentication at all. 
> >>>> It seems safer for MIKEY to always take care of its "own"
> >>>> security, not trusting that someone else does it.
> >>>
> >>> But then why, in case of the pre-shared key scheme, do 
> you allow the 
> >>> use of the NULL MAC and encryption algorithms, when "the 
> underlying 
> >>> protocols
> >>
> >> Yes, this is confusing, we agree. See below for an 
> >> elaboration/clarification.
> >>
> >>> can guarantee security.  The main reason for including 
> this is for 
> >>> specific SIP scenarios, where SDP is protected 
> end-to-end." (section 
> >>> 4.2.4). Why allow to delegate integrity protection to 
> lower layers 
> >>> in the case of PSK, and not for D-H?
> >>
> >> First of all, the intended use of "pre-shared with NULL" is as
> >> follows:
> >>
> >> Security for multimedia in general, and in particular 
> integration of 
> >> key mgmt in SIP, is perhaps not yet an "everyday thing". It is 
> >> therefore likely that developers will want to experiment (inter-op 
> >> tests etc) with the protocol(s). When you do the first 
> initial tests, 
> >> you are really mainly concerned that the "communication" 
> works, and 
> >> you would like to be sure that basic message parsing etc, works 
> >> before you make things more likely to go wrong by adding 
> >> cryptography...;-) Therefore, the NULL mechanism's intended use is 
> >> during testing, where you really don't care if you achieve 
> security 
> >> or not; you're just happy enough if you get it to work...
> >>
> >> Now, a "NULL" algorithm is essentially the same, regardless of if 
> >> it's "pre-shared NULL", or "public-key NULL". We needed a way to 
> >> signal NULL security for testing, and we made the 
> arbitrary choice of 
> >> doing that via the pre-shared mode. We could just as well have 
> >> defined a NULL public-key transform for this purpose.
> >>
> >> We agree that this is not well documented, and is probably 
> something 
> >> we should take care of in a future update. As you will see 
> though, we 
> >> raise strong warning flags against using the NULL options, and we 
> >> fell uncomfortable about introducing more NULL options: while any 
> >> non-authentiocated mode probably can be attacked, D-H is notorious 
> >> for its sensitivity to MITM, so we think that using D-H with NULL 
> >> authentication (perhaps by mistake) is particularly sensitive to 
> >> attacks.
> >>
> >> Hope this provides some rationale.
> >>
> >> Best,
> >>
> >> /Mats
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> msec mailing list
> >> [email-masked]
> >> http://six.pairlist.net/mailman/listinfo/msec
> >
> > -----------------------------------------------------------
> >     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:  [email-masked]
> > -----------------------------------------------------------
> >
> >
> > _______________________________________________
> > msec mailing list
> > [email-masked]
> > http://six.pairlist.net/mailman/listinfo/msec
> >
> 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec