Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[LinkSec] Three cases in single link scenario



Hello all
 
Below is a proposal that has initial focus in single link security. The proposal is to develop approximately three scenarios in parallel instead of choosing only man-in-the-middle case. For following telecom regulations, operators do not have to consider man-in-the-middle in wired networks. They are not held responsible against physical intervention because they have to follow regulations of certain level of physical protection. If the man-in-the-middle "over engineering" comes with added cost, there has to be a lower-cost alternative to be competitive.
 
Important customers may require protection against man-in-the-middle. Therefore, this case deserves attention too.
 
 
Below are the cases. The accompanying text is intended to show the differences between the cases in support of developing all three cases in parallel.
 
1) Man-in-the-middle attack possible; by solving this, one solves any imaginable attack
    To attack:
        -Requires physical intervention in wired networks
        -Requires relatively sophisticated equipment and expertise to avoid getting caught
    To protect:
        -A large spectrum of malicious behaviour must be covered
        -Most probably a shared secret or other shared information is recuired for establishing secure connection
 
In 2) and 3), man in-the-middle case is not considered
 
2) Eavesdropping in both directions possible
    To attack:
        -Requires physical intervention in wired point-to-point networks
        -After the tap has been inserted, eavesdropping is simple with standard PC
        -Theoretically in rare cases possible in EPON without physical intervention
    To protect:
        -Establishing encrypted connection is possible even without shared information.
        -Easier to authenticate packets than in case 1)
3) EPON. Eavesdropping in one direction easy, in other direction very limited
    To attack:
        -Extremely tempting to do in EPON because physical intervention is not required and risk of getting caught is practically non-existent
    To protect:
        -Same advantages as in case 2)
        -May be lower cost than 2) because initially upstream traffic may be unencrypted. Doing this involves a small risk, however
        -Sending encryption keys upstream in clear text may be considered too risky.
 
In cases 2) and 3) a suitable level of protection against replay and jamming should be considered. Both attacks will probably impair bit error ratio severely so they may be detected easily.
    

Antti Pietiläinen
Nokia Research Center
P.O. Box 407
00045 NOKIA GROUP
Finland
tel. +358(0)71-8036660, fax. +358(0)71-8036214

-----Original Message-----
From: ext Dolors Sala [mailto:dolors@ieee.org]
Sent: 22 April, 2003 04:10
To: LinkSec
Subject: [LinkSec] Consensus on Scope?

There seems to be significant consensus in leaving the scenario of untrusted bridges for a later stage (although the final unified architecture should support a complete secure bridge network solution). It seems we may be close to identify the scope of the initial project.
 
In the last call, Bob Moskowitz recommended to initially focus on the link level and leave the entire bridge network definition for a later stage. If I interpret him correctly, he considers that there is enough work in defining the provider side of the link security specification because it doesn't exist an specification or example from where we can leverage from. This work would involve to specify the (bi-directional) authentication and the link protection components of the unified architecture. Bob please clarify or extend as you feel appropriate.
 
We would need to guarantee that the initial effort defines components that fit the unified and general architecture. Could we guarantee this by imposing a set of general requirements to an initial link specification?
 
If so we could define a gradual roadmap where we focus first on the link components and later on the bridged network components. We could first focus on capturing a complete set of requirements from the unified architecture and define an initial project to specify a link security for 802.3 links. At a later stage, additional projects would be defined to complete the architecture for bridged networks (and/or other links if needed).
 
I would like to solicit opinions and comments on this roadmap approach and recommendations on the specific scope and components of an initial project.
 
Dolors