RE: [LinkSec] Meeting material
Mats,
It is my intention (and I hope to pursuade 802.1 to this effect) that any permitted combination of cipher/integrity mode be an entry in the cipher suite. No combination would be allowed that wasn't in the ciphersuite table. The purpose being to inhibit unwise combinations.
Of course there are the vendor proprietary and playpen areas if you want to do something of greater or lesser wisdom.
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: Mats Näslund [mailto:mats.naslund@ericsson.com]
> Sent: Tuesday, September 23, 2003 10:53 AM
> To: mick_seaman@ieee.org
> Cc: Johnston, Dj; LinkSec
> Subject: 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
> >>
> >>
>
>