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