Re: CTP Issue 22: Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits
"James Kempf" <[email protected]>
| Newsgroups | gmane.ietf.seamoby |
|---|---|
| Message-ID | <02b601c37c90$d251d8e0$956015ac@dclkempt40> |
> Maybe it's time to insert rationality back into security protocol design.
> I'm willing to stand the heat.
Does that mean that you're willing to take over as WG chair? :-)
>Mainly I am concerned about data fields
> that have to be passed over the air. Conservatism is indicated for this
> reason, and the reward is less hogging the airwaves.
>
Sure.
> I am not worried about silicon, but in fact it would be nice if we
> did try to avoid mandating every protocol to require a Pentium
> processor.
>
Well, ok, we can leave it at 32 bits, but if we get this thrown back into
our face by the IESG, I'm going to say "I told you so!"
jak
> Regards,
> Charlie P.
>
>
> James Kempf wrote:
>
> >Hi Charlie,
> >
> >These are good arguments, but I don't see them swaying the security
> >directorate. Assuming one instruction per cycle and perhaps 100
instructions
> >to check, a 2 GHz Pentium can check about 20 million tokens per second.
> >Assuming 200 ms active time, that's about 4 million tokens in the time
that
> >the token is active.
> >
> >One can argue with the details of the above calculation, but it is the
kind
> >of thing I'd expect to see pop out of a security review. Of course, I
> >suppose we could argue that the document is Experimental anyway, so
perfect
> >security isn't necessary, but what's the harm in lengthening the field?
> >
> > jak
> >
> >----- Original Message -----
> >From: "Charlie Perkins" <[email protected]>
> >To: "James Kempf" <[email protected]>
> >Cc: <[email protected]>
> >Sent: Tuesday, September 16, 2003 12:34 PM
> >Subject: Re: [Seamoby] CTP Issue 22: Authorization Token is obtained by
> >truncating the results of the HMAC_SHA1 computation to retain only the
> >leading 32 bits
> >
> >
> >
> >
> >>Hello James,
> >>
> >>I don't think it is needed, for two reasons:
> >>
> >>- The authorization token is only going to be used once
> >>
> >>- The data being protected is only good for a few hundred
> >> milliseconds at most (typically).
> >>
> >>Regards,
> >>Charlie P.
> >>
> >>
> >>James Kempf wrote:
> >>
> >>
> >>
> >>>Issue 22 suggests that 32 bits isn't enough for the authorization
token.
> >>>
> >>>See http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue22 for
> >>>
> >>>
> >details.
> >
> >
> >>>Possible resolutions:
> >>>
> >>>1) Make the authorization token longer, say 64 bits.
> >>>2) Keep the authorization token at 32 bits.
> >>>
> >>>Suggested resolution: Make the authorization token longer, say 64 bits.
> >>>Justification: The probability of a birthday attack is proportional to
> >>>2**(sqrt(n)), where n is the number of bits in the identifier. If n is
> >>>
> >>>
> >32,
> >
> >
> >>>then sqrt(n) is 16, which is not enough protection (65536). Making n
> >>>
> >>>
> >equal
> >
> >
> >>>64 means sqrt(n) is 32 (over 4 billion) which should be enough.
> >>>
> >>>
> >>>_______________________________________________
> >>>Seamoby mailing list
> >>>[email protected]
> >>>https://www1.ietf.org/mailman/listinfo/seamoby
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>