Re: Issue 152: Need crypto protocol agility
From: Pasi.Eronen (Pasi.Eronennokia.com)
Date: Wed, 30 Jul 2008 08:08:31 -0700 (PDT)
After talking with Tim, I think using MD5 (and not having agility) is
acceptable in this context -- but the document needs to explain why a
cryptographically secure hash function isn't needed in this particular
place (e.g. in security considerations section).

(Also, the text should just say "A 16-octet MD5 hash of the
image" and have reference to RFC 1321; the pseudo-code is 
confusing since e.g. the variable names in different parts
of it don't match.)

Best regards,
Pasi 

> -----Original Message-----
> From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] 
> Sent: 29 July, 2008 18:53
> To: Margaret Wasserman
> Cc: capwap [at] frascone.com; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: RE: [Capwap] Issue 152: Need crypto protocol agility
> 
> Pasi, are you OK with this?
> 
> PatC 
> 
> -----Original Message-----
> From: Margaret Wasserman [mailto:margaret [at] thingmagic.com] 
> Sent: Tuesday, July 29, 2008 1:44 AM
> To: Pat Calhoun (pacalhou)
> Cc: capwap [at] frascone.com; Pasi.Eronen [at] nokia.com
> Subject: Re: [Capwap] Issue 152: Need crypto protocol agility
> 
> I agree with Pat's reasoning about this being a non-security- 
> sensitive
> checksum and would prefer not to change this section to add hash
> agility.
> 
> Margaret
> 
> 
> On Jul 28, 2008, at 7:48 PM, Pat Calhoun (pacalhou) wrote:
> 
> > All,
> >
> > Pasi's comment is:
> >
> >   Section 4.6.29: Using MD5 in a new protocol, and not providing 
> > algorithm
> >   agility for moving to new algorithms, is probably not 
> such a great 
> > idea
> >
> > Specifically, the text currently looks like:
> >
> > <current text>
> > 4.6.29.  Image Information
> >
> >    The Image Information message element is present in the 
> Image Data
> >    Response message sent by the AC to the WTP and contains the 
> > following
> >    fields.
> >
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
> 7 8 9 0 1
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                           File Size                  
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                              Hash                    
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                              Hash                    
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                              Hash                    
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                              Hash                    
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Type:   29 for Image Information
> >
> >    Length:   20
> >
> >    File Size:   A 32-bit value containing the size of the file, in
> >       bytes, that will be transferred by the AC to the WTP.
> >
> >    Hash:   A 16 octet hash of the image.  The hash is computed using
> >       MD5, using the following pseudo-code:
> >
> >            #include <md5.h>
> >            CapwapCreateHash(char *hash, char *image, int image_len)
> >            {
> >                    MD_CTX context;
> >
> >                    MDInit (&context);
> >                    MDUpdate (&context, buffer, len);
> >                    MDFinal (hash, &context);
> >            }
> > </current text>
> >
> > Certainly, it is possible to create a new field immediately 
> following 
> > the File Size field, called Algorithm Identifier. This field would 
> > dictate the alg used in the generation of the Hash. This change is 
> > fairly simple and straightforward.
> >
> > ... But. There are two things that I'd like to raise here.
> >
> > 1. The hash is not created for security purposes, but rather for 
> > validation purposes. So I question whether we really need to worry 
> > about
> > MD5 not being OK when creating a hash that is used to validate the 
> > contents. Even if MD5 was/is compromised, the purpose of this hash 
> > does not compromise anything. In fact, notice there is no "secret" 
> > used here either. So nothing is at risk.
> >
> > 2. This change would break backward CAPWAP interoperability.
> >
> > Because of issue number two (2), I'd like to get the WG's 
> opinion on 
> > whether this change would be addressed, or rejected.
> >
> > Pasi, any comments on this?
> >
> > PatC
> >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone.com/pipermail/capwap
> 
> 

Results generated by Tiger Technologies using MHonArc.