Subject: [MSEC] Re: Gen-Art Review: draft-ietf-msec-srtp-tesla-03.txt

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 18 Jul 2005 15:28:35 -0400

Resending Elwyn's review thread to the MSEC list so others in the MSEC 
list can participate in the discussion.

regards,
Lakshminath

Elwyn Davies wrote:

> Glad to be of assistance  :-)
>
> I just saw David (M)'s reply also.
>
> As regards avt's view of the world, that is not something I know about 
> and you are in a better position to know.  IMHO the TESLA addition 
> would seem to give the sort of extra facility that an application 
> would understand and would justify a new profile.  As I understand it 
> there are currently two profiles RTP and  SRTP with maybe another one 
> in the pipeline - I am not sure that four doesn't count as very low... 
> Maybe avt count 1, 2, Many O:-)
>
> Maybe the security and application AD's should give an opinion on this.
>
> Regards,
> Elwyn
>
>
>
> Elisabetta Carrara (AL/EAB) wrote:
>
>> Hi!
>> yes, thanks for your review, Elwyn.
>> You are correct -- we should have not defined a transform independent 
>> parameter. Indeed, there is already a transform independent parameter
>> that can be used to flag the use of TESLA, the "identifier for the 
>> message authentication algorithm". Once TESLA is flagged (via MIKEY
>> or sdescription), then there is the logic to understand the added
>> field.
>> Hence, we propose to follow the first of your suggestion, basically
>> take away the definition of the transform independent parameter, and 
>> go for the appropriate IANA registration of TESLA_in_SRTP as
>> new value for the already existing "identifier for the message 
>> authentication algorithm".
>>
>> (Note also, we know that the avt group does not want to have many RTP 
>> profiles, they have explicitly stated to expect the number of 
>> profiles to be very low.)
>>
>> Thanks again
>> cheers
>> /E
>>
>>
>>
>>  
>>
>>> -----Original Message-----
>>> From: David A. McGrew [mailto:[email-masked]]
>>> Sent: den 18 juli 2005 15:06
>>> To: Elwyn Davies
>>> Cc: [email-masked]; canetti Canetti; Mark Baugher; David R Oran;
>>> Elisabetta Carrara (AL/EAB); Russ Housley
>>> Subject: Re: Gen-Art Review: draft-ietf-msec-srtp-tesla-03.txt
>>>
>>>
>>> Elwyn,
>>>
>>> thanks for the detailed explanation.  You are right about the 
>>> transform independent parameter.  I think (and I believe that Mark 
>>> and Elisabetta do as well) that it would be best to eliminate it 
>>> from the spec but keep the current approach in that doc.
>>>
>>> David
>>>
>>> On Jul 15, 2005, at 1:22 AM, Elwyn Davies wrote:
>>>
>>>   
>>>
>>>> Hi.
>>>>
>>>> The technical point that came over as a red flag was that you are 
>>>> adding a new transform independent parameter (begiining of     
>>>
>>> s4.3 in the   
>>>
>>>> TESLA draft) and that is *not* (if I understand SRTP correctly) 
>>>> something which you can do in the course of defining a new 
>>>> authentication transform.  I think it breaks interoperability, but 
>>>> I will bow to more informed sources if this is not so.  Also     
>>>
>>> there is no   
>>>
>>>> way to carry this flag in the MIKEY SRTP policy payload (s6.10.1 of 
>>>> RFC3830).
>>>>
>>>> If I am correct about the technical point above, the exact     
>>>
>>> status quo   
>>>
>>>> is not an option but I think you have two choices:
>>>> - define the combination of the existing RFC3711 authentication and 
>>>> TESLA as a new authentication method - you can then do away with 
>>>> the Transform Independent parameter - applications can then 
>>>> negotiate on which authentication algorithm to use (basic or 
>>>> basic+TESLA) as intended.
>>>> - define a new RTP profile as I suggested offering traffic stream 
>>>> encryption and authentication + source authentication., as compared 
>>>> with existing traffic stream encryption and authentication
>>>>
>>>> The choice between these is to some extent philosophical, I     
>>>
>>> guess.  My   
>>>
>>>> personal feeling is that the addition of TESLA pushes the     
>>>
>>> envelope of   
>>>
>>>> what basic SRTP is supposed to do: adding TESLA to the     
>>>
>>> authentication   
>>>
>>>> algorithm is not simply switching from one mathematical function to 
>>>> another but adds logical capabilities - don't get me wrong, I 
>>>> understand this is a good thing - rather than (say) just using a 
>>>> longer key.  To that extent it is something which an     
>>>
>>> application would   
>>>
>>>> maybe want to select as a profile (and there might turn out to be 
>>>> other ways of doing source authentication that could be subsumed in 
>>>> the same profile!).  Its maybe a bit more work to do a new     
>>>
>>> profile but   
>>>
>>>> avoids overloading the existing profile.
>>>>
>>>> In either case some additional work has to be done in sdescriptions 
>>>> (but you knew that ;-) ) and MIKEY to support TESLA.
>>>>
>>>> Regards,
>>>> Elwyn
>>>>
>>>> PS
>>>> The other comments are independent of this choice and need to be 
>>>> looked at as well!
>>>>
>>>> E
>>>>
>>>>
>>>> David A. McGrew wrote:
>>>>
>>>>     
>>>>
>>>>> Mark, Elwyn,
>>>>>
>>>>> FWICT, a new RTP profile for TESLA isn't advantageous.  It       
>>>>
>>> occurs to   
>>>
>>>>> me that, in addition to the reasons that Mark mentions, there are 
>>>>> cases in which it might be desirable to use TESLA authentication 
>>>>> in conjunction with SRTP encryption.  This case is easier to 
>>>>> handle in SRTP than with a combination of multiple profiles.  
>>>>> Also, re-using the SRTP profile for TESLA allows the re-use of the 
>>>>> signaling mechanisms that have been developed for that profile.  
>>>>> The current methods of signaling SRTP crypto algorithms would 
>>>>> allow the user to negotiate TESLA, were that option available, so 
>>>>> I don't see the benefit of using a separate profile.  (It may be 
>>>>> that I'm missing some point on how profiles, rather than profile 
>>>>> options, are negotiated.  If this is the case, please let me know.)
>>>>>
>>>>> David
>>>>>
>>>>> On Jul 14, 2005, at 10:25 AM, Mark Baugher wrote:
>>>>>
>>>>>       
>>>>>
>>>>>> Thank you for the comments, one of which is major while         
>>>>>
>>> others might   
>>>
>>>>>> merit only editorial consideration.  So, let's take the         
>>>>>
>>> big comment   
>>>
>>>>>> first, the suggestion that SRTP-TESLA should be a new RTP profile 
>>>>>> (please see inline, below).
>>>>>>
>>>>>> On Jul 14, 2005, at 3:49 AM, Elwyn Davies wrote:
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> Background for those on the CC list, who may be unaware of GenART:
>>>>>>> GenART is the Area Review Team for the General Area of the 
>>>>>>> IETF.  We advise the General Area Director (i.e. the IETF/IESG 
>>>>>>> chair) by providing more in depth reviews than he could do 
>>>>>>> himself of documents that come up for final decision in IESG 
>>>>>>>           
>>>>>>
>>> telechat.  I was   
>>>
>>>>>>> selected as the GenART member to review this document.            
>>>>>>
>>> Below is my   
>>>
>>>>>>> review, which was written specifically with an eye to the GenART 
>>>>>>> process, but since I believe that it will be useful to have 
>>>>>>> these comments more widely distributed, others outside the 
>>>>>>> GenART group are being copied.
>>>>>>>
>>>>>>> Document: draft-ietf-msec-srtp-tesla-03.txt
>>>>>>> Intended Status: Proposed Standard
>>>>>>> Shepherding AD: Russ Housely
>>>>>>> Review Trigger: IETF Last call  ended 11 July 2005
>>>>>>>
>>>>>>> Summary:
>>>>>>> In my opinion this document is not ready to go to the           
>>>>>>
>>> IESG.  It has   
>>>
>>>>>>> (in my view)significant issues.  The major one is whether (for 
>>>>>>> technical reasons) it can be treated as an optional add-on to 
>>>>>>> the SRTP RTP profile, and even if it can, whether it would be 
>>>>>>> better treated as a separate profile, facilitating application 
>>>>>>>           
>>>>>>
>>> negotiation   
>>>
>>>>>>> of specific capabilities - i.e., stream 
>>>>>>> encryption/authentication (use SRTP), rigorous source 
>>>>>>> authentication (add TESLA).  I am not an expert in this area so 
>>>>>>> it is quite possible that I am wrong about the technical point 
>>>>>>> but I think making it a           
>>>>>>
>>> separate profile   
>>>
>>>>>>> would have merit irrespective of the technical issue.
>>>>>>>           
>>>>>>
>>>>>>  SRTP-TESLA is simply a new authentication transform for the SRTP 
>>>>>> framework and should be viewed as such.  From Section 1 of         
>>>>>
>>> RFC 3711:
>>>   
>>>
>>>>>> "
>>>>>>   SRTP provides a framework for encryption and message 
>>>>>> authentication
>>>>>>   of RTP and RTCP streams (Section 3).  SRTP defines a set of 
>>>>>> default
>>>>>>   cryptographic transforms (Sections 4 and 5), and it allows new
>>>>>>   transforms to be introduced in the future (Section 6).  With
>>>>>>   appropriate key management (Sections 7 and 8), SRTP is secure
>>>>>>   (Sections 9) for unicast and multicast RTP applications         
>>>>>
>>> (Section   
>>>
>>>>>> 11).
>>>>>> "
>>>>>> As a framework, SRTP aspires to accommodate new and updated 
>>>>>> transforms in order to stay competitive with advances in 
>>>>>> computing power and crypto-analysis.  SRTP as a framework can 
>>>>>> also         
>>>>>
>>> accommodate   
>>>
>>>>>> special-purpose transforms for specific applications, such as 
>>>>>> large-scale multicast with one or more senders.  That's what this 
>>>>>> I-D specifies.  It is business as usual for the RTP/SAVP         
>>>>>
>>> profile to   
>>>
>>>>>> add a new authentication transform.  We would not develop         
>>>>>
>>> a new RTP   
>>>
>>>>>> profile if we chose to add HMAC-MD5 to SRTP and we would not do 
>>>>>> it with TESLA, which is just an authentication transform, albeit 
>>>>>> a complicated one.
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> In the process of reviewing this, I identified a           
>>>>>>
>>> potential problem   
>>>
>>>>>>> in RFC4082 - a telegraph pole problem with the length of the key 
>>>>>>> chain - which has some knock-on effects into this specification.
>>>>>>>           
>>>>>>
>>>>>> Whether we need to fix a potential problem in RFC 4082 or address 
>>>>>> the other detailed comments below should be resolved once we all 
>>>>>> agree that there need to no new RTP profile for SRTP-TESLA.
>>>>>>
>>>>>> I propose the status quo: No need for a new RTP profile.
>>>>>>
>>>>>> cheers, Mark
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> Detailed Review:
>>>>>>>
>>>>>>> Substantive points:
>>>>>>>
>>>>>>> Is this a separate RTP profile?
>>>>>>> I have some difficulty understanding how the proposal can be an 
>>>>>>> optional extension of SRTP:  This is proposed in s4.3 to be 
>>>>>>> implemented by adding a new flag to the Transform Independent 
>>>>>>> parameters of the SRTP cryptographic context.  The intention 
>>>>>>> appears to be that the proposal reverts to RFC3711 SRTP           
>>>>>>
>>> if this bit   
>>>
>>>>>>> is not set.  Inspection of s3.2.1 of RFC3711 does not reveal a 
>>>>>>> generic flag bit word in which this flag could be placed, so I 
>>>>>>> am at a loss to determine how the proposed enhanced profile can 
>>>>>>> be interoperable with existing implementations of SRTP that do 
>>>>>>> not understand TESLA. It seems to me (from my very naive           
>>>>>>
>>> perspective on   
>>>
>>>>>>> RTP and SDP etc) that SRTP/TESLA has to be a separate RTP 
>>>>>>>           
>>>>>>
>>> profile.    
>>>
>>>>>>> Defining this as a new profile would appear to conform to the 
>>>>>>> general usage of this sort of scheme - an application can 
>>>>>>>           
>>>>>>
>>> negotiate   
>>>
>>>>>>> for RTP/STP/TESLA if it feels the need, falling back to           
>>>>>>
>>> RTP/SRTP or   
>>>
>>>>>>> plain old RTP if the user will accept the reduced security.  
>>>>>>> From another point of view, it is a whole other capability on 
>>>>>>>           
>>>>>>
>>> top of the   
>>>
>>>>>>> stream security which SRTP provides and conflating it           
>>>>>>
>>> with the SRTP   
>>>
>>>>>>> profile doesn't seem to make sense.  This of course would have 
>>>>>>> knock on effects on the IANA considerations.
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>> Length of the key chain:
>>>>>>> 'A telegraph pole uncertainty?'
>>>>>>> [Note on TESLA intro, RFC4082: S3.2 says that there is one-way 
>>>>>>> chain of length N made up of K_0, K_1, -> K_N... This appears to 
>>>>>>> have N+1 keys but, of course, N links. Is the list of           
>>>>>>
>>> keys wrong or   
>>>
>>>>>>> does the length give the number of links?]
>>>>>>> This uncertainty links to item 10 of s4.3 - just how many 
>>>>>>>           
>>>>>>
>>> keys are   
>>>
>>>>>>> there in a key chain of length n_c?  Is this number the number 
>>>>>>> of links or the number of keys?
>>>>>>>
>>>>>>> --------
>>>>>>>
>>>>>>> SRTCP average packet size:
>>>>>>> Probably in s4.5 or 4.6, there needs to be a note indicating 
>>>>>>> whether (I think they need to be ) or not the extra           
>>>>>>
>>> fields need to   
>>>
>>>>>>> be incorporated in the 'avg_rtcp_size' (s3.4 of RFC3711,           
>>>>>>
>>> s6.3.3 of   
>>>
>>>>>>> RFC3550). (There is text related to the packet size increase in 
>>>>>>> s6).
>>>>>>>
>>>>>>> ----------
>>>>>>>
>>>>>>> Session Cleanup:
>>>>>>> s5: Firstly, I think the sentence 'This repetition might 
>>>>>>> abruptly stop, however, if the key-bearing packets stop abruptly 
>>>>>>>           
>>>>>>
>>> at the end   
>>>
>>>>>>> of the stream.' is garbled.  Maybe it should be 'The reliability 
>>>>>>> will be compromised if the flow of packets terminates           
>>>>>>
>>> abruptly when   
>>>
>>>>>>> there is no more data to send, so that the keys for the last few 
>>>>>>> previous packets are never sent.'
>>>>>>>
>>>>>>> In the next sentence the implementer is instructed to 'send null 
>>>>>>> packets with TESLA keys for one entire interval'.. how           
>>>>>>
>>> many and how   
>>>
>>>>>>> frequently?  Presumably this will depend on the length of the 
>>>>>>> interval and some view of the reliability but I think guidance 
>>>>>>> is required.
>>>>>>>
>>>>>>> ------------
>>>>>>>
>>>>>>> IANA Considerations:
>>>>>>> s8 claims this document has no registration requirements. 
>>>>>>>           
>>>>>>
>>> This does   
>>>
>>>>>>> not appear to be true.
>>>>>>> If, as I suggest above , this is really a separate RTP           
>>>>>>
>>> profile, the   
>>>
>>>>>>> document defines an RTP profile which needs to be named and 
>>>>>>> registered [RFC3711].
>>>>>>> Whether or not this needs to be done, the specification needs to 
>>>>>>> define one or more registries for the One Way Function           
>>>>>>
>>> identifiers   
>>>
>>>>>>> (CTANs in the terminology of draft-ietf-msec-tesla-spec-00.txt), 
>>>>>>> and maybe the overall cryptographic context.
>>>>>>>
>>>>>>> ============
>>>>>>>
>>>>>>> Semi-substantive:
>>>>>>>
>>>>>>> Key and MAC lengths:
>>>>>>> s4.1/s4.2/s4.5: The lengths of the Disclosed Key and TESLA MAC 
>>>>>>> fields are determined by the one way functions used to setup the 
>>>>>>> key chain and generate the MAC.  This is discussed in           
>>>>>>
>>> 4.3: It would   
>>>
>>>>>>> save head scratching to mention this earlier since the packet 
>>>>>>> format doesn't have explicit lengths.
>>>>>>>
>>>>>>> s4.2: Just for clarification, the Disclosed Key and TESLA MAC 
>>>>>>> fields are specified as variable length.  The figures           
>>>>>>
>>> show them as   
>>>
>>>>>>> ending on 32 bit boundaries.  Is this merely for convenience in 
>>>>>>> drawing or is there any constraint on the length of the fields.  
>>>>>>> Presumably it would be at least good for them to be           
>>>>>>
>>> multiples of 8   
>>>
>>>>>>> bits.
>>>>>>>
>>>>>>> s6.2: This section specifies various options for the OWF and the 
>>>>>>> key and MAC lengths generated.  It doesn't say they are in bits, 
>>>>>>> and it would be worth linking the lengths to the 'Disclosed Key' 
>>>>>>> and 'TESLA MAC' fields in s4.1/4.2.  Also, mentioning           
>>>>>>
>>> that RFC2104   
>>>
>>>>>>> defines HMAC-SHA1 would be helpful.
>>>>>>>
>>>>>>> ----------
>>>>>>> Dealing with Disclosed Keys in Sender and Receiver:
>>>>>>> s4.4.1: Item 6: A few words indicating that the disclosed key 
>>>>>>> possibly needs to be updated from what was sent previously (and 
>>>>>>> what drives this) would be useful.
>>>>>>>
>>>>>>>
>>>>>>> s4.4.2: para 6: Since this part is couched as a set of 
>>>>>>> processing to be performed on a current packet, the start of the 
>>>>>>> second sentence might be better as: 'Check if the current packet 
>>>>>>>           
>>>>>>
>>> contains   
>>>
>>>>>>> a new disclosed key from the current time, the time           
>>>>>>
>>> interval of the   
>>>
>>>>>>> last disclosed key and the key disclosure interval:  if the 
>>>>>>> disclosed key is a new one, determine the index of the           
>>>>>>
>>> key.  If any   
>>>
>>>>>>> keys in the chain have not been received as a result of lost 
>>>>>>> packets, calculate the intervening keys (give a ref to           
>>>>>>
>>> how). Using   
>>>
>>>>>>> these newly obtained keys, perform TESLA verification on any 
>>>>>>> buffered packets to which they apply using the rollover           
>>>>>>
>>> counter...'
>>>   
>>>
>>>>>>> ----------
>>>>>>> Optionality of TESLA:
>>>>>>> TESLA is specified as an optional profile.. I found the words in 
>>>>>>> the 'Note' sentence of the captions of Figures 2 and 3           
>>>>>>
>>> confusing...   
>>>
>>>>>>> It could be read as TESLA fields being optional on a per packet 
>>>>>>> basis.  Everything about the 'optionality of TESLA' is           
>>>>>>
>>> said in the   
>>>
>>>>>>> paragraph before each figure in a much clearer way.  Suggest 
>>>>>>> omitting these sentences.
>>>>>>>
>>>>>>> ------------
>>>>>>> HMAC-SHA1 is default, not only possibility for MAC algorithm?
>>>>>>> s4.6: last para: This appears to imply that HMAC-SHA1 is           
>>>>>>
>>> the *only*   
>>>
>>>>>>> possible algorithm for calculating the TESLA MAC.  This seems to 
>>>>>>> contradict s4.3, Item 5 where the MAC algorithm is specified as 
>>>>>>> a parameter.   This needs to be clarified/corrected.
>>>>>>>
>>>>>>> Editorial Nits:
>>>>>>> global: s/bytes/octets/ (3 instances)
>>>>>>> global: consistency of usage of f/f' vs F/F' for the OWFs
>>>>>>> Abstract: s/loss/Loss/
>>>>>>> s1, para 3: s/discern/distinguish/
>>>>>>> s1, last para: s/loss/Loss/
>>>>>>> s1.1, para 2: s/familiar/is familiar/
>>>>>>> s3, para 3: S/needed/necessary/
>>>>>>> s4.1, para 1: s/The fields added by TESLA are called "TESLA 
>>>>>>> authentication extensions" altogether/The fields added by TESLA, 
>>>>>>> considered as a group, are called "TESLA authentication           
>>>>>>
>>> extensions/
>>>   
>>>
>>>>>>> s4.4.1, s4.4.2: s/included/inclusive/
>>>>>>> s4.4.1: Item 9: It would not hurt to expand ROC (rollover 
>>>>>>>           
>>>>>>
>>> counter).
>>>   
>>>
>>>>>>> s4.4.2: s/is the following/is as follows/
>>>>>>> s4.6: para 5 (1st bullet): s/as for/as described in/
>>>>>>> s4.6: para 6 (2nd bullet): s/as for Section 4.2/as described in 
>>>>>>> Section 4.5/
>>>>>>> s6.2/s11: RFC2104 is referenced in s6.2 (and elsewhere) but the 
>>>>>>> reference is missing. It might be useful to put this ref against 
>>>>>>> the first usage of HMAC-SHA1 in this section (although it 
>>>>>>>           
>>>>>>
>>> has been   
>>>
>>>>>>> refeerenced before).
>>>>>>> s6.2: A reference back to the definitions of the crypto context 
>>>>>>> variables in s4.3 would help.
>>>>>>> s6.2:  OUTPUT LENGTH of TESLA KEYCHAIN OWF is n_p
>>>>>>> s11: References to RFC2119 and RFC2104 are missing.
>>>>>>>
>>>>>>>
>>>>>>> Background for those on the CC list, who may be unaware of
>>>>>>> GenART:
>>>>>>> GenART is the Area Review Team for the General Area of the
>>>>>>> IETF.  We advise the General Area Director (i.e. the
>>>>>>> IETF/IESG chair) by providing more in depth reviews than he
>>>>>>> could do himself of documents that come up for final
>>>>>>> decision in IESG telechat.  I was selected as the GenART
>>>>>>> member to review this document.  Below is my review, which
>>>>>>> was written specifically with an eye to the GenART process,
>>>>>>> but since I believe that it will be useful to have these
>>>>>>> comments more widely distributed, others outside the GenART
>>>>>>> group are being copied.
>>>>>>>
>>>>>>> Document: draft-ietf-msec-srtp-tesla-03.txt
>>>>>>> Intended Status: Proposed Standard
>>>>>>> Shepherding AD: Russ Housely
>>>>>>> Review Trigger: IETF Last call  ended 11 July 2005
>>>>>>>
>>>>>>> Summary:
>>>>>>> In my opinion this document is not ready to go to the
>>>>>>> IESG.  It has (in my view)significant issues.  The major
>>>>>>> one is whether (for technical reasons) it can be treated as
>>>>>>> an optional add-on to the SRTP RTP profile, and even if it
>>>>>>> can, whether it would be better treated as a separate
>>>>>>> profile, facilitating application negotiation of specific
>>>>>>> capabilities - i.e., stream encryption/authentication (use
>>>>>>> SRTP), rigorous source authentication (add TESLA).  I am
>>>>>>> not an expert in this area so it is quite possible that I
>>>>>>> am wrong about the technical point but I think making it a
>>>>>>> separate profile would have merit irrespective of the
>>>>>>> technical issue.
>>>>>>>
>>>>>>> In the process of reviewing this, I identified a potential
>>>>>>> problem in RFC4082 - a telegraph pole problem with the
>>>>>>> length of the key chain - which has some knock-on effects
>>>>>>> into this specification.
>>>>>>>
>>>>>>> Detailed Review:
>>>>>>>
>>>>>>> Substantive points:
>>>>>>>
>>>>>>> Is this a separate RTP profile?
>>>>>>> I have some difficulty understanding how the proposal can
>>>>>>> be an optional extension of SRTP:  This is proposed in s4.3
>>>>>>> to be implemented by adding a new flag to the Transform
>>>>>>> Independent parameters of the SRTP cryptographic context.
>>>>>>> The intention appears to be that the proposal reverts to
>>>>>>> RFC3711 SRTP if this bit is not set.  Inspection of s3.2.1
>>>>>>> of RFC3711 does not reveal a generic flag bit word in which
>>>>>>> this flag could be placed, so I am at a loss to determine
>>>>>>> how the proposed enhanced profile can be interoperable with
>>>>>>> existing implementations of SRTP that do not understand
>>>>>>> TESLA. It seems to me (from my very naive perspective on
>>>>>>> RTP and SDP etc) that SRTP/TESLA has to be a separate RTP
>>>>>>> profile.  Defining this as a new profile would appear to
>>>>>>> conform to the general usage of this sort of scheme - an
>>>>>>> application can negotiate for RTP/STP/TESLA if it feels the
>>>>>>> need, falling back to RTP/SRTP or plain old RTP if the user
>>>>>>> will accept the reduced security.  From another point of
>>>>>>> view, it is a whole other capability on top of the stream
>>>>>>> security which SRTP provides and conflating it with the
>>>>>>> SRTP profile doesn't seem to make sense.  This of course
>>>>>>> would have knock on effects on the IANA considerations.
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>> Length of the key chain:
>>>>>>> 'A telegraph pole uncertainty?'
>>>>>>> [Note on TESLA intro, RFC4082: S3.2 says that there is one-
>>>>>>> way chain of length N made up of K_0, K_1, -> K_N... This
>>>>>>> appears to have N+1 keys but, of course, N links. Is the
>>>>>>> list of keys wrong or does the length give the number of
>>>>>>> links?]
>>>>>>> This uncertainty links to item 10 of s4.3 - just how many
>>>>>>> keys are there in a key chain of length n_c?  Is this
>>>>>>> number the number of links or the number of keys?
>>>>>>>
>>>>>>> --------
>>>>>>>
>>>>>>> SRTCP average packet size:
>>>>>>> Probably in s4.5 or 4.6, there needs to be a note
>>>>>>> indicating whether (I think they need to be ) or not the
>>>>>>> extra fields need to be incorporated in the 'avg_rtcp_size'
>>>>>>> (s3.4 of RFC3711, s6.3.3 of RFC3550). (There is text
>>>>>>> related to the packet size increase in s6).
>>>>>>>
>>>>>>> ----------
>>>>>>>
>>>>>>> Session Cleanup:
>>>>>>> s5: Firstly, I think the sentence 'This repetition might
>>>>>>> abruptly stop, however, if the key-bearing packets stop
>>>>>>> abruptly at the end of the stream.' is garbled.  Maybe it
>>>>>>> should be 'The reliability will be compromised if the flow
>>>>>>> of packets terminates abruptly when there is no more data
>>>>>>> to send, so that the keys for the last few previous packets
>>>>>>> are never sent.'
>>>>>>>
>>>>>>> In the next sentence the implementer is instructed to 'send
>>>>>>> null packets with TESLA keys for one entire interval'.. how
>>>>>>> many and how frequently?  Presumably this will depend on
>>>>>>> the length of the interval and some view of the reliability
>>>>>>> but I think guidance is required.
>>>>>>>
>>>>>>> ------------
>>>>>>>
>>>>>>> IANA Considerations:
>>>>>>> s8 claims this document has no registration requirements.
>>>>>>> This does not appear to be true.
>>>>>>> If, as I suggest above , this is really a separate RTP
>>>>>>> profile, the document defines an RTP profile which needs to
>>>>>>> be named and registered [RFC3711].
>>>>>>> Whether or not this needs to be done, the specification
>>>>>>> needs to define one or more registries for the One Way
>>>>>>> Function identifiers (CTANs in the terminology of draft-
>>>>>>> ietf-msec-tesla-spec-00.txt), and maybe the overall
>>>>>>> cryptographic context.
>>>>>>>
>>>>>>> ============
>>>>>>>
>>>>>>> Semi-substantive:
>>>>>>>
>>>>>>> Key and MAC lengths:
>>>>>>> s4.1/s4.2/s4.5: The lengths of the Disclosed Key and TESLA
>>>>>>> MAC fields are determined by the one way functions used to
>>>>>>> setup the key chain and generate the MAC.  This is
>>>>>>> discussed in 4.3: It would save head scratching to mention
>>>>>>> this earlier since the packet format doesn't have explicit
>>>>>>> lengths.
>>>>>>>
>>>>>>> s4.2: Just for clarification, the Disclosed Key and TESLA
>>>>>>> MAC fields are specified as variable length.  The figures
>>>>>>> show them as ending on 32 bit boundaries.  Is this merely
>>>>>>> for convenience in drawing or is there any constraint on
>>>>>>> the length of the fields.  Presumably it would be at least
>>>>>>> good for them to be multiples of 8 bits.
>>>>>>>
>>>>>>> s6.2: This section specifies various options for the OWF
>>>>>>> and the key and MAC lengths generated.  It doesn't say they
>>>>>>> are in bits, and it would be worth linking the lengths to
>>>>>>> the 'Disclosed Key' and 'TESLA MAC' fields in s4.1/4.2.
>>>>>>> Also, mentioning that RFC2104 defines HMAC-SHA1 would be
>>>>>>> helpful.
>>>>>>>
>>>>>>> ----------
>>>>>>> Dealing with Disclosed Keys in Sender and Receiver:
>>>>>>> s4.4.1: Item 6: A few words indicating that the disclosed
>>>>>>> key possibly needs to be updated from what was sent
>>>>>>> previously (and what drives this) would be useful.
>>>>>>>
>>>>>>>
>>>>>>> s4.4.2: para 6: Since this part is couched as a set of
>>>>>>> processing to be performed on a current packet, the start
>>>>>>> of the second sentence might be better as: 'Check if the
>>>>>>> current packet contains a new disclosed key from the
>>>>>>> current time, the time interval of the last disclosed key
>>>>>>> and the key disclosure interval:  if the disclosed key is a
>>>>>>> new one, determine the index of the key.  If any keys in
>>>>>>> the chain have not been received as a result of lost
>>>>>>> packets, calculate the intervening keys (give a ref to
>>>>>>> how). Using these newly obtained keys, perform TESLA
>>>>>>> verification on any buffered packets to which they apply
>>>>>>> using the rollover counter...'
>>>>>>>
>>>>>>> ----------
>>>>>>> Optionality of TESLA:
>>>>>>> TESLA is specified as an optional profile.. I found the
>>>>>>> words in the 'Note' sentence of the captions of Figures 2
>>>>>>> and 3 confusing... It could be read as TESLA fields being
>>>>>>> optional on a per packet basis.  Everything about the
>>>>>>> 'optionality of TESLA' is said in the paragraph before each
>>>>>>> figure in a much clearer way.  Suggest omitting these
>>>>>>> sentences.
>>>>>>>
>>>>>>> ------------
>>>>>>> HMAC-SHA1 is default, not only possibility for MAC
>>>>>>> algorithm?
>>>>>>> s4.6: last para: This appears to imply that HMAC-SHA1 is
>>>>>>> the *only* possible algorithm for calculating the TESLA
>>>>>>> MAC.  This seems to contradict s4.3, Item 5 where the MAC
>>>>>>> algorithm is specified as a parameter.   This needs to be
>>>>>>> clarified/corrected.
>>>>>>>
>>>>>>> Editorial Nits:
>>>>>>> global: s/bytes/octets/ (3 instances)
>>>>>>> global: consistency of usage of f/f' vs F/F' for the OWFs
>>>>>>> Abstract: s/loss/Loss/
>>>>>>> s1, para 3: s/discern/distinguish/
>>>>>>> s1, last para: s/loss/Loss/
>>>>>>> s1.1, para 2: s/familiar/is familiar/
>>>>>>> s3, para 3: S/needed/necessary/
>>>>>>> s4.1, para 1: s/The fields added by TESLA are called "TESLA
>>>>>>> authentication extensions" altogether/The fields added by
>>>>>>> TESLA, considered as a group, are called "TESLA
>>>>>>> authentication extensions/
>>>>>>> s4.4.1, s4.4.2: s/included/inclusive/
>>>>>>> s4.4.1: Item 9: It would not hurt to expand ROC (rollover
>>>>>>> counter).
>>>>>>> s4.4.2: s/is the following/is as follows/
>>>>>>> s4.6: para 5 (1st bullet): s/as for/as described in/
>>>>>>> s4.6: para 6 (2nd bullet): s/as for Section 4.2/as
>>>>>>> described in Section 4.5/
>>>>>>> s6.2/s11: RFC2104 is referenced in s6.2 (and elsewhere) but
>>>>>>> the reference is missing. It might be useful to put this
>>>>>>> ref against the first usage of HMAC-SHA1 in this section
>>>>>>> (although it has been refeerenced before).
>>>>>>> s6.2: A reference back to the definitions of the crypto
>>>>>>> context variables in s4.3 would help.
>>>>>>> s6.2:  OUTPUT LENGTH of TESLA KEYCHAIN OWF is n_p
>>>>>>> s11: References to RFC2119 and RFC2104 are missing.
>>>>>>>
>>>>>>>           
>>>>>>
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Thu, 21 Jul 2005 09:47:35 -0700

Elwyn,

On Jul 14, 2005, at 3:49 AM, Elwyn Davies wrote:
...
> Summary:
> In my opinion this document is not ready to go to the IESG.  It has  
> technical reasons) it can be treated as an optional add-on to the SRTP  
> RTP profile, and even if it can, whether it would be better treated as  
> a separate profile, facilitating application negotiation of specific  
> capabilities - i.e., stream encryption/authentication (use SRTP),  
> rigorous source authentication (add TESLA).  I am not an expert in  
> this area so it is quite possible that I am wrong about the technical  
> point but I think making it a separate profile would have merit  
> irrespective of the technical issue.

I think we all agree that if we remove the transport-independent  
parameter from the crypto context data structure, then SRTP-TESLA is  
properly viewed as a new authentication transform for SRTP.  SRTP-TESLA  
is signaled in the key management, offer/answer, announcement protocol,  
etc.  There is an I-D that describes signaling bindings in an IANA  
registration for MIKEY.  We will need SRTP-TESLA bindinds for SDP  
Security Descriptions once the group/multicast version of the security  
descriptions offer/answer exchange is complete.

In addition to removing the transport-dependent parameter as Elisabetta  
proposed, I promised Colin Perkins that we'll explain why SRTP does not  
have profiles but instead interprets the layout of the SRTP packet  
according to its transforms, which are replaceable and upgradeable.   
(There is an I-D from RMT that does add TESLA using a new profile, such  
is not the case with SRTP where we treat TESLA as a new authentication  
transform.)
>
> In the process of reviewing this, I identified a potential problem in  
> RFC4082 - a telegraph pole problem with the length of the key chain -  
> which has some knock-on effects into this specification.

You actually identified quite a bit and I'll comment further on the  
substantive points of your detailed review.  Regarding the "telegraph  
pole" problem, the error in RFC4082 (section 3.2) is inconsequential  
AFAICT.

> parameters of the SRTP cryptographic context.  The intention appears  
> to be that the proposal reverts to RFC3711 SRTP if this bit is not  
> set.  Inspection of s3.2.1 of RFC3711 does not reveal a generic flag  
> bit word in which this flag could be placed, so I am at a loss to  
> determine how the proposed enhanced profile can be interoperable with  
> existing implementations of SRTP that do not understand TESLA. It  
> seems to me (from my very naive perspective on RTP and SDP etc) that  
> SRTP/TESLA has to be a separate RTP profile.  Defining this as a new  
> profile would appear to conform to the general usage of this sort of  
> scheme - an application can negotiate for RTP/STP/TESLA if it feels  
> the need, falling back to RTP/SRTP or plain old RTP if the user will  
> accept the reduced security.  From another point of view, it is a  
> whole other capability on top of the stream security which SRTP  
> provides and conflating it with the SRTP profile doesn't seem to make  
> sense.  This of course would have knock on effects on the IANA  
> considerations.

Yes, we need to remove the flag but IANA considerations should be  
clarified and state that the key management protocol that establishes  
TESLA keys will register SRTP-TESLA bindings.  This is being done for  
MIKEY in  
http://www.ietf.org/internet-drafts/draft-ietf-msec-bootstrapping- 
tesla-01.txt but SDP Security Descriptions does not yet support  
multicast SRTP and there are no bindings for SRTP-TESLA.
> [Note on TESLA intro, RFC4082: S3.2 says that there is one-way chain  
> of length N made up of K_0, K_1, -> K_N... This appears to have N+1  
> keys but, of course, N links. Is the list of keys wrong or does the  
> length give the number of links?]

The number is typically so large that this error does not matter.

> This uncertainty links to item 10 of s4.3 - just how many keys are  
> there in a key chain of length n_c?  Is this number the number of  
> links or the number of keys?

I think you mean item 11.  I don't think it matters if the key chain  
only supports 999,999 packets instead of a million.
> Probably in s4.5 or 4.6, there needs to be a note indicating whether  
> (I think they need to be ) or not the extra fields need to be  
> incorporated in the 'avg_rtcp_size' (s3.4 of RFC3711, s6.3.3 of  
> RFC3550). (There is text related to the packet size increase in s6).

Thanks.
>
> ----------
>
> Session Cleanup:
> s5: Firstly, I think the sentence 'This repetition might abruptly  
> stop, however, if the key-bearing packets stop abruptly at the end of  
> the stream.' is garbled.  Maybe it should be 'The reliability will be  
> compromised if the flow of packets terminates abruptly when there is  
> no more data to send, so that the keys for the last few previous  
> packets are never sent.'

Thanks.  How about "Since the key for time interval i is disclosed in  
i+1, it follows that a stream with n time intervals must continue  
through n+1 to disclose all keys."
> packets with TESLA keys for one entire interval'.. how many and how  
> frequently?  Presumably this will depend on the length of the interval  
> and some view of the reliability but I think guidance is required.

I think this is well defined as the packet field "i" that is shown in  
Fig. 1.

>
> ------------
>
> IANA Considerations:
> s8 claims this document has no registration requirements. This does  
> not appear to be true.
> If, as I suggest above , this is really a separate RTP profile, the  
> document defines an RTP profile which needs to be named and registered  
> [RFC3711].
> define one or more registries for the One Way Function identifiers  
> (CTANs in the terminology of draft-ietf-msec-tesla-spec-00.txt), and  
> maybe the overall cryptographic context.

We should mention that key management uses and registers the names, all  
we are naming in this I-D are packet fields.  We could reference  
http://www.ietf.org/internet-drafts/draft-ietf-msec-bootstrapping- 
tesla-01.txt to illustrate.
>
> ============
>
> Semi-substantive:
>
> Key and MAC lengths:
> s4.1/s4.2/s4.5: The lengths of the Disclosed Key and TESLA MAC fields  
> are determined by the one way functions used to setup the key chain  
> and generate the MAC.  This is discussed in 4.3: It would save head  
> scratching to mention this earlier since the packet format doesn't  
> have explicit lengths.

Okay.
>
> s4.2: Just for clarification, the Disclosed Key and TESLA MAC fields  
> are specified as variable length.  The figures show them as ending on  
> 32 bit boundaries.  Is this merely for convenience in drawing or is  
> there any constraint on the length of the fields.  Presumably it would  
> be at least good for them to be multiples of 8 bits.

Everything is a multiple of 8 bits but not 32.  We should say that.
>
> s6.2: This section specifies various options for the OWF and the key  
> and MAC lengths generated.  It doesn't say they are in bits, and it  
> would be worth linking the lengths to the 'Disclosed Key' and 'TESLA  
> MAC' fields in s4.1/4.2.  Also, mentioning that RFC2104 defines  
> HMAC-SHA1 would be helpful.

Okay.
> s4.4.1: Item 6: A few words indicating that the disclosed key possibly  
> needs to be updated from what was sent previously (and what drives  
> this) would be useful.
>

I don't understand what you mean by "the disclosed key possibly needs  
to be updated."

>
> s4.4.2: para 6: Since this part is couched as a set of processing to  
> be performed on a current packet, the start of the second sentence  
> might be better as: 'Check if the current packet contains a new  
> disclosed key from the current time, the time interval of the last  
> disclosed key and the key disclosure interval:  if the disclosed key  
> is a new one, determine the index of the key.  If any keys in the  
> chain have not been received as a result of lost packets, calculate  
> the intervening keys (give a ref to how).
This is in section 3.5 of RFC 4082, and the reader must be familiar  
with this section to understand 4.4.2 of srtp-tesla, which references  
sections 3.5-3.7 of RFC 4082.  We chose to reference rather than  
reproduce in detail the processing of RFC 4082.

> Using these newly obtained keys, perform TESLA verification on any  
> buffered packets to which they apply using the rollover counter...'

I'm not sure what we are fixing here.
>
> ----------
> Optionality of TESLA:
> TESLA is specified as an optional profile.. I found the words in the  
> 'Note' sentence of the captions of Figures 2 and 3 confusing... It  
> could be read as TESLA fields being optional on a per packet basis.   
> Everything about the 'optionality of TESLA' is said in the paragraph  
> before each figure in a much clearer way.  Suggest omitting these  
> sentences.

Ok, but we don't refer to TESLA as an optional profile.  I think it's  
best understood as an authentication transform that may be chosen for  
certain applications.
None other are currently defined in RFC 3711.
> s4.6: last para: This appears to imply that HMAC-SHA1 is the *only*  
> contradict s4.3, Item 5 where the MAC algorithm is specified as a  
> parameter.   This needs to be clarified/corrected.
We should clarify this because if HMAC-MD5 or some other MAC is defined  
for SRTP, it probably can be used for SRTP-TESLA as well.
> considered as a group, are called "TESLA authentication extensions/
> s4.4.1: Item 9: It would not hurt to expand ROC (rollover counter).
> reference is missing. It might be useful to put this ref against the  
> first usage of HMAC-SHA1 in this section (although it has been  
> refeerenced before).
Thanks for your comments

Mark