Subject: [MSEC] http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-00.txt

From: Mark Baugher <[email-masked]>
Date: Wed, 18 Aug 2004 13:37:09 -0700

Andrea, Hugh
   Hugh asked me to take a look at the SRTP bindings in  
http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec 
-00.txt.  These need to be consistent with RFC 3711, specifically page  
36, and I think that they mostly are.  I am using  
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions 
-07.txt, pp. 11-18, to jog my memory.

   The policy token bindings for SRTP are missing the session parameters  
from  
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions 
-07.txt, page 16.  RTP has an RTCP feed-back channel and SRTCP can be  
configured to be encrypted or not.  sdescriptions includes this  
parameter.  So does p. 36 of RFC 3711 but it's not obvious that SRTP  
and SRTCP each have their own pair of transform definitions.  Thus it's  
possible to use NULL encryption for SRTCP while use AES-CM or f8 for  
SRTP.  What we have not supported in either sdescriptions, or MIKEY I  
think, is setting a different authentication or encryption algorithm  
for SRTCP and SRTP - beyond allowing NULL encryption for SRTCP.

   Also, authentication is not optional for SRTCP, but only for SRTP -  
and then it is NOT RECOMMENDED for anything but voice.  So the  
authentication can't be OPTIONAL in the SRTCP case at least.

   Regarding From/To and MKI, there are two things that need to be  
conveyed.  The first is a boolean that indicates whether either one are  
used for the session (as you note in the I-D, one can't use both).  The  
second item is the length of the MKI when the MKI is used.

   Finally, there is FEC, which is specified for RTP and supported in  
SRTP.  We have including three FEC orderings.  I think more needs to be  
said about FEC and SRTP that is not covered in RFC 3711.  But for our  
purposes, I think if you stick to the definitions inn RFC 3711, the  
policy token will at least be consistent.

Mark

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