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 >>
>
>