headers
Marcus Leech | 2 May 2005 17:59
Favicon

Problems with draft-ietf-mmusic-sdescriptions-09.txt

One of my colleagues pointed me at this document.    Quite apart from 
whatever problems might
  exist in the protocol itself, it makes an assumption that it will 
always run of "some kind of secure
  channel".  It's not clear how that's enforced, and given that this 
protocol is carrying keying material
  for SRTP, it makes me nervous.

Can others take a look and tell me whether I'm out to lunch or not?  [In 
this specific case, not
  the more general case of me being out to lunch, since I already know 
that :-) ].

--

-- 
Marcus Leech                            Mail:   Dept 1A12, M/S: 04352P16
Security Standards Advisor        Phone: (ESN) 393-9145  +1 613 763 9145
Advanced Technology Research
Nortel Networks                          mleech <at> nortel.com
Permalink | Reply | 6 comments |
headers
Cullen Jennings | 3 May 2005 19:27
Picon
Favicon
Gravatar

Re: Problems with draft-ietf-mmusic-sdescriptions-09.txt


I guess this work could be used by many application protocols but the one I
am most interested in is SIP so let me answer your question for that one.

The application, a SIP UA, in this case needs to decide how it wants the
material to be protected - if it does not care, it could just send it. If it
wants to enforce all hops use hop by hop protection, it would use a sips
URL, it it wanted to enforce end to end protection, it could use the S/MIME
stuff. All these are somewhat described in 3261.

I imagine for other application that use this the answer would be similar.
Any application that has keying material needs to decide how and when to
protect it and not much some lower level thing can do about that.

Cullen

On 5/2/05 8:59 AM, "Marcus Leech" <mleech <at> nortel.com> wrote:

> One of my colleagues pointed me at this document.    Quite apart from
> whatever problems might
>   exist in the protocol itself, it makes an assumption that it will
> always run of "some kind of secure
>   channel".  It's not clear how that's enforced, and given that this
> protocol is carrying keying material
>   for SRTP, it makes me nervous.
> 
> Can others take a look and tell me whether I'm out to lunch or not?  [In
> this specific case, not
>   the more general case of me being out to lunch, since I already know
> that :-) ].
(Continue reading)

Permalink | Reply | 0 comments |
headers
Blumenthal, Uri | 3 May 2005 19:52
Picon
Favicon

RE: Problems with draft-ietf-mmusic-sdescriptions-09.txt

> I guess this work could be used by many application protocols but the
one I
> am most interested in is SIP so let me answer your question for that
one.

Most likely it will be used by SIP.

> The application, a SIP UA, in this case needs to decide how it wants
the
> material to be protected - if it does not care, it could just send it.
If it
> wants to enforce all hops use hop by hop protection, it would use a
sips
> URL, it it wanted to enforce end to end protection, it could use the
S/MIME
> stuff. All these are somewhat described in 3261.

I haven't touched SIP for quite a while - and I don't think may SIP
applications (especially those from 3GPP/3GPP2) support S/MIME.
Since this proposal suggests sending keys themselves - unless it is
demonstrated how the application will *enforce* end-to-end security, the
proposed protocol has a nice hop-to-hop hole in it.

> I imagine for other application that use this the answer would be
similar.

:-)

> Any application that has keying material needs to decide how and when
to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jari Arkko | 3 May 2005 21:23

Re: Problems with draft-ietf-mmusic-sdescriptions-09.txt

Just FYI that MMUSIC actually has two drafts that can provide
keys for things like media streams:

- draft-ietf-mmusic-sdescriptions-09.txt, which more or less
  tells you to send a key in plaintext, but assumes that there's
  some underlying transport security (tls or s/mime).

- draft-ietf-mmusic-kmgmt-ext-14.txt, which is an integrated
  key management protocol approach. Basically, you run
  Mikey (RFC 3830) within an SDP attribute, end-to-end.
  This includes authentication of the endpoints as well
  as protection for the negotiated data, independent of
  the security or lack of it for any of the SIP hops.

--Jari
Permalink | Reply | 0 comments |
headers
Blumenthal, Uri | 3 May 2005 23:42
Picon
Favicon

RE: Problems with draft-ietf-mmusic-sdescriptions-09.txt

The apparent concern of Marcus and me is that the first of these two
methods (sdescriptions) makes unreasonable assumptions (regarding
underlying protection level) that it cannot verify, and which are not
spelled out explicitly (such as minimum requirements, the consequences
of adhering and non-adhering, and means to verify that these
requirements are satisfied).

I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and
"mmusic-sdescriptions" wants to do that.

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko <at> piuha.net] 
Sent: Tuesday, May 03, 2005 3:24 PM
To: Blumenthal, Uri
Cc: Cullen Jennings; Marcus Leech; saag <at> mit.edu
Subject: Re: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt

Just FYI that MMUSIC actually has two drafts that can provide
keys for things like media streams:

- draft-ietf-mmusic-sdescriptions-09.txt, which more or less
  tells you to send a key in plaintext, but assumes that there's
  some underlying transport security (tls or s/mime).

- draft-ietf-mmusic-kmgmt-ext-14.txt, which is an integrated
  key management protocol approach. Basically, you run
  Mikey (RFC 3830) within an SDP attribute, end-to-end.
  This includes authentication of the endpoints as well
  as protection for the negotiated data, independent of
  the security or lack of it for any of the SIP hops.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Baugher | 3 May 2005 23:59
Picon
Favicon

Re: Problems with draft-ietf-mmusic-sdescriptions-09.txt


On May 3, 2005, at 2:42 PM, Blumenthal, Uri wrote:

> The apparent concern of Marcus and me is that the first of these two
> methods (sdescriptions) makes unreasonable assumptions (regarding
> underlying protection level) that it cannot verify, and which are not

Any application that requires a secure connection whether it be TLS or 
IPsec needs to have a policy, enforce a policy and verify that the 
policy is enforced.  What exactly is the problem?

> spelled out explicitly (such as minimum requirements, the consequences
> of adhering and non-adhering, and means to verify that these
> requirements are satisfied).

We do not state a particular policy for the application in the I-D that 
is true.  I see that you return to the problem of being able to verify 
whether there is a secure connection in place or not.  Why do you think 
that the endsystems cannot determine this?
>
> I wonder why "mmusic-kmgmt-ext" is not enough for key passing, and
> "mmusic-sdescriptions" wants to do that.

There exists no infrastructure today to support kmgmt or MIKEY.  I 
think that's fairly obvious, isn't it?

Mark
>
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko <at> piuha.net]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael.G.Williams | 4 May 2005 16:47
Picon

RE: Problems with draft-ietf-mmusic-sdescriptions-09.txt

Colleagues,

Picking up on the thread below about secure connections, and
applications logic or protocol stack implementations wanting to verify
what security is in force....

There is some consideration of the various issues of conveying that
information within a stack, and across a connection, within the IEEE for
layer 2 secure connections.

Discussions include the lack of a standardized "trust model" within a
protocol stack (O/S specific, beyond the level of interoperability in
specs, part of API, etc) Also, how to indicate any form of security is
in place at L2, and should such indications be available to other layers
directly, or to a management entity, etc.

It would be helpful to hear input from this group about the possible
utility of an L2 indication to some arbitrary receiver that security is
in effect, and what form that indication might usefully take. 

Best Regards,
Michael G. Williams
IEEE 802.21 WG Vice Chair 

-----Original Message-----
From: saag-bounces <at> mit.edu [mailto:saag-bounces <at> mit.edu] On Behalf Of
Mark Baugher
Sent: Tuesday, May 03, 2005 2:59 PM
To: Blumenthal, Uri
Cc: saag <at> mit.edu
(Continue reading)

Permalink | Reply | 11 comments |
headers
Blumenthal, Uri | 4 May 2005 17:10
Picon
Favicon

RE: Problems with draft-ietf-mmusic-sdescriptions-09.txt

The concern wrt. L2 security is that it is hop-by-hop. So even if upper
layers could learn useful things about the protection provided by the
underlying layers - it would last (for L2) only till the next hop.

Having said that - it would be very nice to have a standard way of
finding out what's the protection level given and upon what
credentials...

-----Original Message-----
From: Michael.G.Williams <at> nokia.com [mailto:Michael.G.Williams <at> nokia.com]

Sent: Wednesday, May 04, 2005 10:47 AM
To: mbaugher <at> cisco.com; Blumenthal, Uri
Cc: saag <at> mit.edu
Subject: RE: [saag] Problems with draft-ietf-mmusic-sdescriptions-09.txt

Colleagues,

Picking up on the thread below about secure connections, and
applications logic or protocol stack implementations wanting to verify
what security is in force....

There is some consideration of the various issues of conveying that
information within a stack, and across a connection, within the IEEE for
layer 2 secure connections.

Discussions include the lack of a standardized "trust model" within a
protocol stack (O/S specific, beyond the level of interoperability in
specs, part of API, etc) Also, how to indicate any form of security is
in place at L2, and should such indications be available to other layers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Leech | 4 May 2005 17:25
Favicon

Re: Problems with draft-ietf-mmusic-sdescriptions-09.txt


Michael.G.Williams <at> nokia.com wrote:

>Colleagues,
>
>Picking up on the thread below about secure connections, and
>applications logic or protocol stack implementations wanting to verify
>what security is in force....
>
>There is some consideration of the various issues of conveying that
>information within a stack, and across a connection, within the IEEE for
>layer 2 secure connections.
>
>Discussions include the lack of a standardized "trust model" within a
>protocol stack (O/S specific, beyond the level of interoperability in
>specs, part of API, etc) Also, how to indicate any form of security is
>in place at L2, and should such indications be available to other layers
>directly, or to a management entity, etc.
>
>It would be helpful to hear input from this group about the possible
>utility of an L2 indication to some arbitrary receiver that security is
>in effect, and what form that indication might usefully take. 
>
>Best Regards,
>Michael G. Williams
>IEEE 802.21 WG Vice Chair 
>
>  
>
If the application is only interested in the security of the first hop,
(Continue reading)

Permalink | Reply | 10 comments |
headers
Michael Richardson | 4 May 2005 20:05
Picon

Re: Problems with draft-ietf-mmusic-sdescriptions-09.txt


>>>>> "Marcus" == Marcus Leech <mleech <at> nortel.com> writes:
    Marcus> I will assert (with some expected flamage) that L2 security
    Marcus> technologies, such as they are, are largely designed to
    Marcus> protect the *revenue* of the L2 network operator.  802.11i,
    Marcus> for example, really only protects the first hop, and because
    Marcus> of ARP spoofing, can only reasonably be expected to "lock
    Marcus> out" those who haven't paid/registered, but it can't

  Not only that, it doesn't protect the beacon, so with AP-spoofing is
possible.  Given a settlement system that permits roaming from wireless
network to wireless network, with operators collecting fees, 802.11i
doesn't even protect the *revenue* stream.

--

-- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr  <at>  xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Permalink | Reply | 9 comments |

Gmane