Subject: [MMUSIC] draft-baugher-mmusic-sdpmediasec-00.txt: some questions

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 25 Nov 2002 16:50:25 +0100

Hello Mark, 

let me raise a coupe of questions regarding your draft.

1.) section 3.0 states "A new SDP attribute called "crypto" describes the
cryptographic and security-session parameters for one or more media entries
(a=crypto MUST NOT appear at the SDP session level)." 

whereas section 5 allows "Alternatively, by permitting a=crypto to appear at
the SDP session level, we get simpler Offers and Answers." 

This appears at least inconsistent. 

I believe the session level option is very useful, as this offers to reduce
the description complexity when operating only on a session level.
Nevertheless media specific security description should be available too. 

2.) section 3.3: While SRTP currently defines only a single default PRF
function, there should be a facility to express other PRFs (in case SRTP
might need another PRF at some future point in time). 

3.) section 4.3: I'm not convinced yet that concatenating master key and
master salt together and then base64 encode the composition is the most
efficient way for the receiver to separate those two items. Have you
considered base64 encoding the master key and the master salt separately?
e.g., like .../BASE64(key)/BASE64(salt)/... 

4.) section 4.3: lifetime: AFAIK, SRTP specifies the lifetime in terms of
the packet index which is an 48-bit integer whereas your draft just allows
to express the log2 of the packet index. Your way limits the possibilities
significantly.

I also believe that lifetime actually allows to define a beginning and an
end time in a media stream between which the master key is assumed to be
valid. 

How would one define the lifetime for an SRTCP-related master key, that is
defined through the implicit 31-bit packet index? 

5.) section 4.3.2: What exactly is meant by "refreshing the ROC"? Would that
mean that the receiver sets his/her ROC to the conveyed one? What would
happen, if the ROC is set to a value that had passed already? 

6.) section 4.3.3: Which crypto suite/encryption algorithm would be applied
for encryption SRTCP? I believe that SRTP and SRTCP may be encrypted using
different ciphers but that your draft does not allow for this flexibility? 

8.) section 6: "SRTP message integrity and anti-replay mechanisms,
therefore, SHOULD be used. Source authentication of unicast SRTP messages
SHOULD be performed.  Source authentication of multicast SRTP messages is
today non-standard and hence for further study." 

These statements do not mention that SRTP can at least be operated in a
"group authentication" mode and might raise the impression that this is not
possible. 

9.) There are several MUST/MUSTs NOT related to the "sendonly"/"sendrecv". I
wouldn't expect to find such important mandates in the security
considerations section, but rather assume them be part of the procedural
description beforehand. My suggestion is to put those statements into
section 4.3.1. 

10.) The draft prohibits "There are practical cases, however, where SDP
security is not end to end: If there is a third-party provider between the
sender and receiver, then the data-security session might not be end to end.

... 
The SRTP attribute MUST NOT be used when end-to-end authentication or
confidentiality is needed but the SDP message is not secured end to end
(such as the above example where a third-party provider maintains the
security associations with the endpoints for the SDP message)." 

I would argue similarly that there are practical cases where E2E
authentication or confidentiality on the media level is needed but the SDP
message is secured just hop-to-hop and the third party acts as a key
provisioning server. 

Regards, 

Martin Euchner.

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Nov 2002 12:26:37 -0800

Hi Martin,
   Pardon my delay in answering your note.  See my comments below.

At 07:20 PM 11/18/2002 +0000, Martin Euchner wrote:
>Hello Mark,
>
>
>let me raise a coupe of questions regarding your draft. Since I do not 
>have access to my office email rightnow, I can't post this message to the 
>MMUSIC mailing list; but you are free to send the reply to the mailing 
>list meanwhile.
>
>cryptographic and security-session parameters for one or more media 
>entries (a=crypto MUST NOT appear at the SDP session level)."
>
>whereas section 5 allows "Alternatively, by permitting a=crypto to appear 
>at the SDP session level, we get simpler Offers and Answers."
>
>I believe the session level option is very useful, as this offers to 
>reduce the description complexity when operating only on a session level. 

Yes, we decided to allow it just for Offer/Answer;perhaps this it is 
inconsistent to limit it this way.  There are complexities with allowing 
the crypto attribute to appear at the session level.  Please raise this 
issue on the MMUSIC list if you fell so inclined.  I think we should 
discuss it there.

>might need another PRF at some future point in time).

I agree and think that this is handled properly in the I-D:  If one wants 
to change the PRF then one defines a new cipher_suite.  I hope section 
4.1.5 is clear enough on this point. Is it?

>e.g., like …/BASE64(key)/BASE64(salt)/…

No, I have not.  What is the advantage of doing separate encodings?  It 
seems straightforward to me to base64 decode the concatenated keys and then 
separate them.

>to express the log2 of the packet index.

Well the log2 specification is a 48 bit number but I did not see any need 
for such precision over such an enormous range.  Do you think it is needed?

>end time in a media stream between which the master key is assumed to be valid.

I think there is a problem with this definition in SRTP because the start 
value and end value actually should apply to a session key not a master 
key.  Up to four session keys can be derived from a master key, two of 
which are encryption keys that have different sequence number spaces (RTP 
and RTCP).  I think the packets lifetime is more straightforward than the 
start/stop values applied to one of the two sequence number spaces.

>defined through the implicit 31-bit packet index?

I think this is exactly the point I am making above.  We define the packets 
lifetime in terms of a number of packets and this applies to both the SRTP 
and SRTCP packets that are encrypted with session keys that are derived 
from the master key.

>5.) section 4.3.2: What exactly is meant by "refreshing the ROC"? Would 
>that mean that the receiver sets his/her ROC to the conveyed one? What 
>would happen, if the ROC is set to a value that had passed already?

In a broadcast scenario, a receiver may join the session after the rollover 
counter has rolled.  "Refreshing the ROC" is where the receiver gets the 
latest value of the ROC through RTSP/SDP, SAP/SDP, or other means.

>6.) section 4.3.3: Which crypto suite/encryption algorithm would be 
>applied for encryption SRTCP? I believe that SRTP and SRTCP may be 
>encrypted using different ciphers but that your draft does not allow for 
>this flexibility?

No. The same cipher applies to both SRTP and SRTCP.  I cannot think of any 
good reason to support different transforms for each and it adds a lot of 
complexity.  I don't think that MIKEY supports this and I don't expect that 
GDOI will support the signaling of different transforms for SRTP and SRTCP.

>"group authentication" mode and might raise the impression that this is 
>not possible.

Yes, I agree.  We should add something about this in the next version of 
the I-D.

>There are several MUST/MUSTs NOT related to the "sendonly"/"sendrecv". I 

Well, they need to be in the security considerations.  We could duplicate 
them, but why not refer to them in 4.3.1 rather than repeat them?

>The draft prohibits "There are practical cases, however, where SDP 
>…

Interesting that you bring this up since we added this caveat to the GDOI 
I-D last week as a result of IESG Last Call.  So, you're saying that the 
SDP message, specifically the mkey line, can be manipulated en-route by 
proxies and intermediaries?

Thanks for your comments.

best regards, Mark

>Regards,
>
>Martin Euchner.
>
>
>
>
>
>+---------------------------------
>+
>+ email: [email-masked]
>+
>+---------------------------------
>
>
>
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
>http://join.msn.com/?page=features/junkmail