Re: [LinkSec] Meeting material
Mick,
Thanks for the clarifications. The reason I "reacted" is that all 802
standards that have their own security seem to apply the transforms in
this (security sub-optimal) way, and I was hoping it would be fixed now
that we have a more clear-sheet approach.
Indeed, if we end up with both separate cipher/MIC combinations, as well
as "encapsulation" modes (such as OCB), it might be impossible to draw a
single processing-diagram that applies to all transform combinations.
cheers
/mats
Mick Seaman wrote:
> As David says below (re stuff on rhs of my diagram and I said in the meeting yesterday, I am trying to steer a line between being able to show relationships in a diagram (a good thing) and tripping over specifics of security practices (a bad thing) on the other. From the point of view of rapid summary for someone more interested in the network architecture effects having a "large blob" of security transform only guided by words is obscure. I'll continue to try and find a middle course - simply reversing the encryption /integrity placements or trying for a diagram neutral on this point may do the trick. When it gets down to real implementation requirements ("shalls") and algorithms these of course have to be strictly correct. I think the discussion on the composition of cipher suites closes out the possibility of anyone picking an undesirable smorgasbord.
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Johnston,
> Dj
> Sent: Tuesday, September 23, 2003 8:49 AM
> To: Mats Näslund; LinkSec
> Subject: RE: [LinkSec] Meeting material
>
>
>
> Mats,
> Don't read too much into the 'crypto stuff' on the right hand side of the SecY diagram. That doesn't define the algorithm. The current state of discussion is that a generic 'crypto blob' goes there, the packet, KEY and other local state associated with the SA (e.g. replay counter) go in. Plaintext and other goodness comes out the top (or the reverse for Tx).
>
> What is in the 'crypto blob' is determined by the selected ciphersuite entry for the SA which would determine the details of the mode.
>
> Presumably, if we are suitably diligent about what we put in the ciphersuite, we can then state exactly what the security guarantees are for each selection.
>
> What the diagram does do is show the relationship between the controlled/uncrontrolled port and the crypto functions.
>
> DJ
>
>
> David Johnston
> Intel Corporation
> Chair, IEEE 802 Handoff ECSG
>
> Email : dj.johnston@intel.com
> Tel : 503 380 5578 (Mobile)
> Tel : 503 264 3855 (Office)
>
>
>>-----Original Message-----
>>From: owner-stds-802-linksec@majordomo.ieee.org
>>[mailto:owner-stds-802-linksec@majordomo.ieee.org] On Behalf
>>Of Mats Näslund
>>Sent: Tuesday, September 23, 2003 4:12 AM
>>To: LinkSec
>>Subject: Re: [LinkSec] Meeting material
>>
>>
>>
>>
>>Hi,
>>
>>Dolors Sala wrote:
>>
>>>DJ material is now posted at the same page:
>>>
>>>http://www.ieee802.org/linksec/meetings/Sep03/
>>
>>I have two questions regarding some of these.
>>
>>On Don's "format" presentation, p 8, I read:
>>
>>"ICV Size
>>** Birthday attack susceptible modes
>>- Strength proportional to sqrt(2^n) where n is the number of bits"
>>
>>Bits in the tag?
>>
>>This was up for discussion a few weeks ago, and I still wonder
>>what are these modes and attacks? AFAIK, there are no generic
>>birthday attacks on the tag size as such. For iterated MIC
>>constructions, there are birthday attacks, but these attacks depend
>>on the internal state space size, not the tag size (unless
>>they happen
>>to be the same, e.g. as in CBC_MAC). Basically, these attack makes
>>use of the fact that if two distinct messages x, y, end up in the
>>same state after a number of iterations, then for any fixed z,
>>x || z and y || z will have the same tag. Another attack, is that by
>>Breneel et al which actually gets *more* efficient as the tag size
>>increases! I think it is important to be clear on how various
>>parameters relate to security. Of course, there may be an attack
>>that I am not aware of, in wich case I woule be interested to hear
>>about it. In general though, a good MIC should behave like a pseudo
>>random function, and thus, there should be collsions as we approach
>>the "birthday bound".
>>
>>Secondly, on Mick's "SeCY Functions", p 2, if I understand
>>correctly you promote an integrity-before-encryption order.
>>Since we know that this is suboptimal both from DoS-resistance
>>and from cryptographic point of view, I wonder what good rationale
>>there is for still doing so.
>>
>>cheers,
>>
>>/Mats
>>
>>