Subject: [Capwap] Issue 152: Need crypto protocol agility

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 28 Jul 2008 11:48:21 -0700

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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Jul 2008 09:44:20 +0100

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 29 Jul 2008 08:53:29 -0700

Pasi, are you OK with this?

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 1:44 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]; [email-masked]
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:

> 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.
>

---

From: Charles Clancy <[email-masked]>
Date: Tue, 29 Jul 2008 13:34:16 -0400

Pat,

Per Pasi's comments in the meeting, the concern is FIPS 140-2 
compliance.  MD5 may be forbidden regardless of its use.  Looking at 
FIPS 140-2 Annex A, it specifically talks about "Secure Hashes".

I think there are two options -- (1) make it clear that we're not using 
MD5 as a "Secure Hash" in the document, or (2) switch to using CRC which 
is obviously NOT a secure hash.

Tim -- See discussion below.  Would using MD5 for a non-cryptographic 
firmware checksum make FIPS 140-2 compliance difficult?

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 18:06:08 +0300

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 

> From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: 29 July, 2008 18:53
> To: Margaret Wasserman
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: RE: [Capwap] Issue 152: Need crypto protocol agility
> 
> sensitive
> >      |                           File Size                  
>          |
> >      |                              Hash                    
>          |
> >      |                              Hash                    
>          |
> >      |                              Hash                    
>          |
> >      |                              Hash                    
>          |

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 30 Jul 2008 13:57:25 -0700

Ok, sounds good. How about the following?

<text>

      0                   1                   2                   3

   Type:   26 for Image Information

   Length:   20

   Hash:   A 16 octet MD5 hash of the image using the procedures defined
      in [RFC1321]. 

[...]
12.1.5.  Use of MD5

   The Image Information Section 4.6.29) message element makes use of
   MD5 to compute the hash field.  It is important to note that in order
   to preserve interoperability with existing CAPWAP implementations, it
   was decided to not provide protocol agility.  That said, it is also
   important to note that the use of MD5 in this context is to create a
   cryptographically secure hash, but instead to provide a basic
   checksum value.  Therefore, the use of MD5 is not considered a
   security vulnerability.
</text>

PatC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2008 8:06 AM
To: Pat Calhoun (pacalhou); [email-masked]
Cc: [email-masked]
Subject: Re: [Capwap] Issue 152: Need crypto protocol agility

(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

---

From: "Nathan J. Williams" <[email-masked]>
Date: Wed, 30 Jul 2008 17:17:30 -0400

>    important to note that the use of MD5 in this context is to create a
                                                            ^^^
                                                            not

>    checksum value.  Therefore, the use of MD5 is not considered a

Right?

	- Nathan

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 30 Jul 2008 17:17:55 -0400

Pat Calhoun wrote:

>    important to note that the use of MD5 in this context is 
                                                                ^ not
 >    to create a

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 30 Jul 2008 14:59:56 -0700

Oh right. Making sure that everyone is awake ;-)

PatC 

-----Original Message-----
From: Nathan J. Williams [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2008 2:18 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]; Margaret Wasserman; [email-masked]
Subject: Re: [Capwap] Issue 152: Need crypto protocol agility

                                                            ^^^
                                                            not

Right?

	- Nathan

---

From: <[email-masked]>
Date: Thu, 31 Jul 2008 13:25:20 +0300

The text could also mention how the image is protected (if it's
not MD5), and reverse the order of explanation. Something
like this maybe?

"The authenticity and integrity of the image file is protected
by DTLS, and in this context, MD5 is not used as a cryptographically
secure hash, but just as a basic checksum. Therefore, the use
of MD5 is not considered a security vulnerability, and no
mechanisms for algorithm agility are provided."

Best regards,
Pasi

> Sent: 31 July, 2008 01:00
> To: Nathan J. Williams
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); Margaret Wasserman; 
> [email-masked]
> >    to preserve interoperability with existing CAPWAP 
> implementations,
> it
> to create 
> > a

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 31 Jul 2008 10:14:27 -0700

Works for me. Made the change.

Thanks!

PatC 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 31, 2008 3:25 AM
To: Pat Calhoun (pacalhou); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Capwap] Issue 152: Need crypto protocol agility

The text could also mention how the image is protected (if it's not
MD5), and reverse the order of explanation. Something like this maybe?

"The authenticity and integrity of the image file is protected by DTLS,
and in this context, MD5 is not used as a cryptographically secure hash,
but just as a basic checksum. Therefore, the use of MD5 is not
considered a security vulnerability, and no mechanisms for algorithm
agility are provided."

Best regards,
Pasi