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

From: Johan Bilien <[email-masked]>
Date: Fri, 18 Mar 2005 18:56:43 +0100

Hi,

I would like to discuss the possibility of using the Diffie-Hellman
scheme in MIKEY with a digital signature at a higher layer (SIP +
S/MIME for instance).

Having a signature covering the Diffie-Hellman message is necessary to
prevent the man-in-the-middle attack. However, having the option to
place the signature at a higher layer, thus covering more information,
would have several advantages. If we take the example of MIKEY/SDP/SIP:

  . 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
    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.

  . From an implementation point of view, having the authentication at
    the SIP layer also makes sense, since if the authentication fails, a
    SIP message should be sent back (without having to parse the media
    part). It also allows the callee to make filtering decision based on
    the caller's identity, without having to go down to the media layer.

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.

Regards,
Johan.
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mats Näslund <[email-masked]>
Date: Mon, 21 Mar 2005 16:34:14 +0100

Hi Johan,

We discussed your proposal among the MIKEY authors, and we have
the following comments.

>     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.

>     has advantages independant of MIKEY, such as preventing the change

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.

> twice. So I think being able to create unsigned D-H MIKEY messages would

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.

Cheers,

/Mats

---

From: Mark Baugher <[email-masked]>
Date: Mon, 21 Mar 2005 08:02:06 -0800

hi Mats
   When I saw Johan's note, it occurred to me that he should use 
Security Descriptions when SIP with S/MIME is used.  I believe that is 
what is being standardized in the SIP WGs.

Mark

---

From: Johan Bilien <[email-masked]>
Date: Tue, 22 Mar 2005 10:40:06 +0100

> We discussed your proposal among the MIKEY authors, and we have

Thanks for your answer.

> effects since different keys would be created at Initiator/Responder

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
(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).

> off the signature part, delete the MIKEY line, and change SAVP to AVP.

Agreed.

> 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
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?

Best regards,
Johan.

---

From: Mats Näslund <[email-masked]>
Date: Tue, 22 Mar 2005 18:26:12 +0100

Hi Johan,

> 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.

> 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*.

> of the NULL MAC and encryption algorithms, when "the underlying protocols

Yes, this is confusing, we agree. See below for an
elaboration/clarification.

> 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

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 23 Mar 2005 08:51:02 +0100

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]

> >  > >    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
> >  >
> >  >
> >  > 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
> 
> things. Conversely, MIKEY should not have to trust that something else
> takes cares of MIKEY's own security.
> 
> > + SRTP), then you need an authentication at the SIP layer, and end
> > + up
> 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
> is reliable). In other words, MIKEY is intended to be an e2e
> mechanism, but SIP itself may not always be.
> 
> 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.
> >  >
> >  > (perhaps by misstake) using MIKEY-DH without authentication at
> >  > all. It seems safer for MIKEY to always take care of its "own"
> > 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
> 
> > 4.2.4). Why allow to delegate integrity protection to lower layers
> > in the case of PSK, and not for D-H?
> 
> 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...
> 
> "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

-----------------------------------------------------------
    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]
-----------------------------------------------------------

---

From: Johan Bilien <[email-masked]>
Date: Wed, 23 Mar 2005 12:17:21 +0100

> else takes cares of MIKEY's own security.

Having each layer provide each own security mechanism can also be a
hassle and a waste of resource.

> but SIP itself may not always be.

I wasn't mixing hop-by-hop encryption of the signaling with end-to-end
encryption of the media. By "authentication of the SIP message", I mean
end-to-end authentication and integrity protection of the SIP messages,
as suggested in RFC3261 section 23, using S/MIME. This kind of
end-to-end authentication of the caller to the callee is necessary to
prevent voice spam and such.

My point is that both MIKEY/D-H, to prevent man-in-the-middle attacks,
and SIP, to authenticate the users in a call and to protect the media
description (including the MIKEY attribute) from alteration, share the
need for a digital signature, so it would make sence to have a common
one instead of two.

Note that this is not limited to SIP, in any session establishment
mechanism where the media session will be secure with MIKEY/SRTP, you
probably want to authenticate the session establishment messages as
well, and if they carry a MIKEY message you will always end up having
authentication over authentication. Therefore I think it would make
sense to have an option for MIKEY to delegate its authentication to
lower levels.

> other "modes" in MIKEY aimed exactly at constrained applications.

Oh I was not really considering performance issues. It's more for the
sake of making things feel "right" :)

Note though that decoding an RSA digital signature isn't completely
neglictable when compared to deriving a D-H key (factor 10 or
something), see [1].

> well be that interop problems are *created*.

Does that mean that both S/MIME and MIKEY will contain the certificates
for example? Shall the IDs always match?

In a ideal world, MIKEY would be completely independant of other layers.
Unfortunately it is already not the case (just see all the references to
SIP in the MIKEY RFC). For instance, if there is an error in the MIKEY
message, a SIP error message will be returned.

> should take care of in a future update. (...)

Indeed :)

Thanks a lot for this great feedback. I now understand more your point
of view, that MIKEY should be self-contained as much as possible.
However I still think that interactions with other layers cannot be
avoided, and adding having MIKEY know about the authentication
capabilities of lower layers would not be a hassle.

Best regards,
Johan.

[1] http://www.minisip.org/publications/secvoip.pdf
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Tue, 29 Mar 2005 07:06:45 -0800

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