RE: [LinkSec] RE: SecY interface definitions
Mick,
Thanks for the terminology clarification. I misunderstood.
The response time to key end life depends on the encryption algorithm.
Stronger the encryption algorithm, slower the needed response. When the
rekeying mechanism is scheduled properly, then there is no reason for this
indication. If a requirement to key exchange scheduling would be stated, and
it will consider the selected algorithm, then no indication is required. On
the other hand, an ill scheduler and a weak algorithm are a bad combination,
which might require this indication.
Onn.
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mick
> Seaman
> Sent: Sunday, August 17, 2003 5:12 PM
> To: 'Stds-802-Linksec'
> Subject: RE: [LinkSec] RE: SecY interface definitions
>
>
>
> Onn,
>
> I don't understand what you mean by
>
> "If all management information should be exchanged with PAE, is
> there a need
> for
> MACsec? Wouldn't it be better to remove it to avoid confusion?"
>
> MACsec is the standard that defines the SecY and the protocol, so I'm
> mystified.
>
> Separately, how slow is the required response to key end life. If
> it is slow
> enough to cope with temporary loss of connectivity to a key
> server surely it
> is not needed because a regular key update schedule would remove the
> requirement? Or is this an artefact of modelling the storage of keys to be
> used in the short term as being with the PAE as opposed to the
> SecY itself?
>
> Mick
>
> -----Original Message-----
> From: Onn Haran [mailto:onn.haran@passave.com]
> Sent: Sunday, August 17, 2003 1:45 AM
> To: mick_seaman@ieee.org; 'Stds-802-Linksec'
> Subject: RE: [LinkSec] RE: SecY interface definitions
>
>
> Mick,
>
> I will modify the presentation based on your valuable feedback.
>
> Before trying to answer your questions, I would like to ask one: If all
> management information should be exchanged with PAE, is there a need for
> MACsec? Wouldn't it be better to remove it to avoid confusion?
>
> The SEQN in #3 is not packet based. It is the SEQN of the key in
> use. As you
> mentioned, the delivery of a key is not synchronized with data delivery,
> therefore every packet should identify the key in use. For this reason, 2
> bits are sufficient.
>
> I haven't addressed explicitly packet based SEQN, since I don't think it
> should be passed to management interface. Yet, some block cipher mode of
> operation do require that IV should be different for each packet. SEQN per
> packet is one way to support this requirement.
>
> Regarding #7, I don't believe that security will be compromised when an
> event causing all keys to end life will occur. The current keys
> should still
> be in use. The required response time to key end life event
> should be fairly
> slow.
>
> Onn.
>
>
> > -----Original Message-----
> > From: Mick Seaman [mailto:mick_seaman@ieee.org]
> > Sent: Sunday, August 17, 2003 1:39 AM
> > To: 'Onn Haran'; 'Stds-802-Linksec'
> > Subject: RE: [LinkSec] RE: SecY interface definitions
> >
> >
> >
> > Onn,
> >
> > I find the slides very useful and thought provoking.
> >
> > If we are taking strictly about interfaces, a SecY has three interfaces:
> >
> > 1) Upper ISS - the service provided, eventually to a bridge
> relay function
> > (MILSAP) or to and MSAP
> > 2) Lower ISS - the service used - to encode user data and the parameters
> > added by the SecY for transmission in a PDU/frame to a peer
> SecY or SecYs
> > 3) LMI - Layer Management Interface - the standard way of exporting
> > management information to other entities in the same system and
> receiving
> > parameters from them, in this case the most interesting exchange of
> > information is to and from the PAE associated with the same Port as the
> > SecY.
> >
> > In addition, additional information could be transferred between
> > peer SecYs
> > using interface 2, possibly in PDUs that do not carry any user
> > data supplied
> > across interface (1).
> >
> > I believe that we should require all key information exchange to occur
> > between PAEs, and never directly using a SecY. Certainly this
> should apply
> > so far as the SecY is aware - since it is possible to envisage
> a PAE that
> > has interfaces to both the controlled and uncontrolled ports
> (strictly the
> > controlled and uncontrolled partitions of a single Port). Such
> a PAE might
> > use the service provided by a SecY. However I don't think that this is a
> > very good idea, but rather all key information exchange should
> be effected
> > by PAEs using a single MSAP supported by an uncontrolled port.
> >
> > All this fits with the architectural diagrams I presented at the last
> > meeting. Since I have just found that I can't access them on
> the web, I'm
> > attaching these.
> >
> > Specifically on your slides (9 in all):
> >
> > In #2 you ask the question whether key information should remain
> > in 802.1aa
> > or should be part of MACsec:
> >
> > I believe that all exchanges to do with authentication, authorisation,
> > encryption/integrity algorithm selection, initial key information
> > distribution, key information refresh, should be outside the
> > MACsec and the
> > secY.
> >
> > Conceptually the algorithm and key information is excanged by and/or
> > delievered to the PAE (or whatever entity or entities we replace the PAE
> > with) and then it is delivered to the SecY for the port from the
> > PAE for the
> > port using the LMI.
> >
> > This means that delivery of this information is not tightly synchronized
> > with the data delivered from/to the upper ISS (the secY user).
> >
> > In #3 you assume there is a receive and transmit SEQN. I am not
> quite sure
> > why, ais this just to do with an assumption that we should
> > provide an option
> > of replay protection at this layer? (but see below)
> >
> > In #5 you asume that keys are identified by sequence numbers that
> > should be
> > kept as short as possible (2 bits). I can't think why, can you explain?
> > Given what else has to be added to the frame for security this seems tio
> > impose unnecessary constraints on the rest of the design. I don't
> > think keys
> > should be exchanged using the secY in any case - see above.
> >
> > In #7, the fact that operation of the encryption/integrity algorithm may
> > have a finite and not predeterminable (data rate dependent life) thus
> > requiring the secY to signal the PAE (via the LMI) that new
> > keying material
> > may be wanted is interesting. Do we really want to allow algorithms with
> > such properties - it seems that temporary hiccups in the network
> > infrastructure could result in catastrophic failure (or compormising
> > security) if such an algorithm were to be used??
> >
> >
> > It seems that one of the activities we should be starting right
> now is the
> > parade/selection of possible algorithms, including a mandatory
> default for
> > interoperability (in addition to the null algorithm) , and including the
> > advetisement and negotiation procedure used to select an
> > algorithm when two
> > secYs are capable of a number of algorithms, some of which they have in
> > common.
> >
> > Mick
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-linksec@majordomo.ieee.org
> > [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Onn Haran
> > Sent: Tuesday, August 12, 2003 9:37 AM
> > To: Stds-802-Linksec
> > Subject: [LinkSec] RE: SecY interface definitions
> >
> >
> > All,
> >
> > I'm trying to initiate a discussion for defining SecY
> interface. Since the
> > content of SecY is not finalized, I had to make an assumption.
> I hope that
> > my assumption is in line with your view.
> >
> > Onn Haran,
> > Passave << File: SecY interfaces.zip >>
> >
> >
>
>
>