Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt

["Murtaza Chiba (mchiba)" <[e-mail]>]

Hi Jeff, 

> 
> Hi Murtaza,
> 
> On Mar 29, 2008, at 6:21 PM, Murtaza Chiba (mchiba) wrote:
> >
> > In all cases in the specification HMAC is computed before 
> encrypting 
> > blocks (this is only stated earlier in the specification 
> when talking 
> > about the control communication, but is standard for HMAC use).
> >
> > MSC> Since the Control exchange uses stream encryption it makes most
> > sense that the HMAC is calculated before encrypting.   
> However, for  
> > Test
> > packets, since only part of the packet is being encrypted it is not 
> > clear whether the HMAC is a check for the encrypted packet 
> (that is it 
> > is calculated after encryption) or for the packet before encryption.
> > If it is a signature for the encrypted packet then one can check 
> > integrity before decrypting and that speeds-up processing, that is
> > reverse of the process for Control packets.   The other way 
> round, the
> > packet has to be decrypted first (a more expensive process) 
> and then 
> > the signature needs to be verified.
> 
> The optimization you suggest is not without a cost. If the 
> data going into the HMAC and the result of the HMAC are both 
> transmitted in the clear, the HMAC hash function is more 
> susceptible to attack. If this level of optimization is 
> required, I suggest using open mode.
> 

I agree that when using encrypted mode there is a reason to be paranoid
and hence it is preferable to authenticate before encryption.   
How about the authenticated mode?   The reason to use an authenticated
mode could be less to do with security (and hence susceptibility) and
more to do with data integrity.

-Murtaza

> If you believe others could be confused by the fact that it 
> is not explicitly stated that the HMAC is computed on the 
> non-encrypted message contents first (in this part of the 
> RFC), then I would suggest submitting an errata for the RFC.
> 
> jeff
> 
> 
> >
> >
> > -Murtaza
> >
> > So, for the test packets: In authenticated mode, only the 
> first block 
> > is used to generate the HMAC, and then only the first block is 
> > encrypted.
> > In encrypted mode, the HMAC is computed using the first two blocks, 
> > and both of those blocks are encrypted. In both of these cases the 
> > HMAC field is set to the result of hashing the HMAC key 
> with the data 
> > in the blocks using the HMAC-SHA1 algorithm as specified.
> >
> > jeff
> >
> >>
> >> -----Original Message-----
> >> From: Jeff W. Boote [mailto:[e-mail]]
> >> Sent: Friday, March 28, 2008 1:01 PM
> >> To: Murtaza Chiba (mchiba)
> >> Cc: Henk Uijterwaal; IETF IPPM WG
> >> Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt
> >>
> >>
> >> On Mar 28, 2008, at 1:15 PM, Murtaza Chiba (mchiba) wrote:
> >>> Another clarification question.
> >>>
> >>> For Test packets the draft is not clear on the order of 
> encryption 
> >>> and
> >>> authentication.   One can assume that the intent was to first  
> >>> encrypt
> >>> and then authenticate the fields which is the reverse of Control
> >>> packets.   It would be nice to see clarification text in 
> the section
> >>> 4.2.1 of TWAMP and section 4.1.2 of OWAMP.
> >>
> >> I did not go read the TWAMP section to see if the situation is the 
> >> same, but for OWAMP there is no order at all. There are 3 different
> >> 'modes':
> >>
> >> open, encrypted, authenticated.
> >>
> >> These modes are negotiated in the control connection, and which 
> >> process the individual packets go through is defined based on the 
> >> selected mode.
> >> They are independent - there is no order to consider.
> >>
> >> The difference between authenticated and encrypted is that the 
> >> timestamp information is sent unencrypted in authenticated mode to 
> >> reduce the amount of time from when the timestamp was 
> retrieved and 
> >> the packet is actually sent. In encrypted mode, the entire data 
> >> segment is encrypted including the timestamp.
> >>
> >> Perhaps I'm completely missing the point?
> >>
> >> jeff
> >>
> >>
> >>
> >>> -Murtaza
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail] 
> [mailto:[e-mail]] On Behalf 
> >>> Of Murtaza Chiba (mchiba)
> >>> Sent: Tuesday, March 25, 2008 1:10 PM
> >>> To: Henk Uijterwaal
> >>> Cc: IETF IPPM WG
> >>> Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt
> >>>
> >>>
> >>>
> >>> Some more questions on TWAMP draft.
> >>>
> >>> Q1) Section 3.8 Stop Sessions mentions that command can 
> only be sent 
> >>> by
> >>> the Session-Sender.   I believe the authors meant 
> Control-Client as
> >>> the
> >>> Session-Sender does not exchange a control command.
> >>>
> >>> Q2) In the same section it mentions that NO session description 
> >>> record
> >>
> >>> can be sent, however, it also mentions that the Next SeqNo and 
> >>> Number
> >
> >>> of Skip Ranges MUST be set to 0 and those are part of the session
> >>> description record!   I am assuming the authors ONLY meant to  
> >>> exclude
> >>> the no. Skip Ranges record.
> >>>
> >>> Q3) Is it possible to add a SID to a Start-Sessions 
> message?   That
> >>> would help limit the meaning of Active to be per SID allowing for
> >>> different SIDs to be started and stopped on demand.   
> Sometimes one
> >>> may
> >>> want to start a Test Stream in response to an observed network 
> >>> behaviour.
> >>>
> >>> Q4) If the above is acceptable then I propose adding a 
> >>> Control-Command-type field to all response messages and hence the 
> >>> Accept field should be the second field.  It also entails 
> adding a 
> >>> SID
> >>
> >>> in the Requests and Responses.
> >>>
> >>> -Murtaza
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail] 
> [mailto:[e-mail]] On Behalf 
> >>> Of Henk Uijterwaal
> >>> Sent: Monday, March 17, 2008 8:12 AM
> >>> To: Henk Uijterwaal
> >>> Cc: IETF IPPM WG
> >>> Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt
> >>>
> >>> IPPM Group,
> >>>
> >>>> This is a WGLC for the draft: draft-ietf-ippm-twamp-06.txt
> >>>>
> >>>> The draft has been discussed extensively in this group 
> and appears 
> >>>> to
> >>
> >>>> to be stable by now.  We like to start a WGLC in order to move it
> >>> forward.
> >>>> Please raise any remaining issues by Friday, March 14, 9:00 UTC.
> >>>>
> >>>> An URL for the draft is:
> >>>>
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-06.txt
> >>>
> >>> This concludes the WGLC for this draft.  Two issues were 
> raised on 
> >>> the
> >>
> >>> list.  We'll ask the authors to respond to those on the 
> list and to 
> >>> include fixes in the draft.  After that we'll move the document 
> >>> forward.
> >>>
> >>> Matt & Henk
> >>>
> >>>
> >>> --
> >>> 
> --------------------------------------------------------------------
> >>> -
> >>> -
> >>> --
> >>> ------
> >>> Henk Uijterwaal                           Email:
> >>> henk.uijterwaal(at)ripe.net
> >>> RIPE Network Coordination Centre
> >>> http://www.amsterdamned.org/~henk
> >>> P.O.Box 10096          Singel 258         Phone: [phone]
> >>> 1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
> >>> The Netherlands        The Netherlands    Mobile: [phone]
> >>> 
> --------------------------------------------------------------------
> >>> -
> >>> -
> >>> --
> >>> ------
> >>>
> >>> Is one of the choices leaving the office open?
> >>>                                     Alan Greenspan on the next 
> >>> elections _______________________________________________
> >>> ippm mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ippm
> >>> _______________________________________________
> >>> ippm mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ippm
> >>> _______________________________________________
> >>> ippm mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ippm
> >>
> >> jeff
> >> --
> >> Jeff W. Boote
> >> [e-mail]
> >>
> >>
> >>
> >
> > jeff
> > --
> > Jeff W. Boote
> > [e-mail]
> >
> >
> >
> 
> jeff
> --
> Jeff W. Boote
> [e-mail]
> 
> 
> 
> 
> 
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm