| Re: Issue 152: Need crypto protocol agility | <– Date –> <– Thread –> |
|
From: Pat Calhoun (pacalhou) (pcalhoun |
|
| Date: Wed, 30 Jul 2008 13:57:40 -0700 (PDT) | |
Ok, sounds good. How about the following?
<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: 26 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 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: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com]
Sent: Wednesday, July 30, 2008 8:06 AM
To: Pat Calhoun (pacalhou); margaret [at] thingmagic.com
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] Issue 152: Need crypto protocol agility
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
>
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap
- Re: Issue 152: Need crypto protocol agility, (continued)
-
Re: Issue 152: Need crypto protocol agility Margaret Wasserman, July 29 2008
-
Re: Issue 152: Need crypto protocol agility Pat Calhoun (pacalhou), July 29 2008
- Re: Issue 152: Need crypto protocol agility Charles Clancy, July 29 2008
- Re: Issue 152: Need crypto protocol agility Pasi.Eronen, July 30 2008
- Re: Issue 152: Need crypto protocol agility Pat Calhoun (pacalhou), July 30 2008
- Re: Issue 152: Need crypto protocol agility Nathan J. Williams, July 30 2008
- Re: Issue 152: Need crypto protocol agility Pat Calhoun (pacalhou), July 30 2008
- Re: Issue 152: Need crypto protocol agility Pasi.Eronen, July 31 2008
- Re: Issue 152: Need crypto protocol agility Pat Calhoun (pacalhou), July 31 2008
-
Re: Issue 152: Need crypto protocol agility Pat Calhoun (pacalhou), July 29 2008
-
Re: Issue 152: Need crypto protocol agility Margaret Wasserman, July 29 2008
Results generated by Tiger Technologies using MHonArc.