1. Introduction
This
document is intended to set the requirements for a generic security protocol by means of
which two parties can communicate with each other securely and privately, ensuring the
integrity of the messages passed.
The document only sets down the
requirements of such a desired robust protocol: it does not describe any such protocol
itself. The ground for the scenario is
described and hence the capabilities of the attacker.
2. Overview
2.1
Purpose of the Protocol
The
intention of the protocol is its usage in lieu of wireless networks for secure mutual
authentication. However, it is expected that the protocol, when designed / modified from
an existing one, shall be as useful in the wired domain as in the wireless domain. The
reason for mentioning the purpose of the protocol is that the protocol shall be
specifically tailored for the wireless domain.
2.2 Situation under consideration
In
particular, the context in which the protocol shall be deployed assumes a scenario in
which there are a number of wireless devices in the network under consideration. Most of
these devices are initially assumed to be Laptop devices were wireless Ethernet cards are
expected to provide connectivity. Te utility of the protocol is to provide the user with a
secure channel to communicate to another location, be it another wireless device or the
main hub itself. Te extension comes about by
addition of wireless devices that aren’t prone to direct user interaction. Examples
of such wireless devices are wireless cameras, projectors and other resources. The
protocol requirements take no notice of such distinctions: it shall in fact encompass all
possible devices.
2.3 Wireless Devices Implication
Stated
below are the implications of having wireless devices of varying CPU and battery power in
the network. There are quite a few
differences between the wired and the wireless domain. This section is more on the type of
the wireless device rather than the fact that they are wireless: a difference, which
should practically make no difference when the protocol is designed and deployed.
2.3.1 CPU
power: Most of the
Wireless devices are expected to have a very low CPU computing power. The implication of
this is that these devices can’t really be expected to perform huge RSA type
calculations very fast. The protocol design has to ensure the availability and proper
usage of the wireless device. Hence, the protocol may, for instance mandate a certain very
strong cryptographic scheme for a certain device and a relatively weak one for another
device.
2.3.1.a Example: Here strong and weak have
implications in the sense of usage and time constraint. A Laptop may engage in a session
that is a few hours long and a wireless camera in a session that is a few minutes long.
Hence, the “weak” cryptographic scheme may have key reusability duration of an
hour or so, which is however safe enough for the wireless camera.
2.3.2 Battery Power: The battery power of these devices is
also limited: hence the devices are expected to be off and on intermittently (sleeping
mode). This is closely related to the requirement with CPU power in the context of the
protocol providing a differing message exchange scheme and/or cryptographic scheme
(amongst other things ) dependent on the device.
2.4 Security Properties to be considered
2.4.1
Confidentiality
2.4.2
Integrity (and closely related Authenticity)
2.4.3
Availability: Apart
from 2.4.1 and 2.4.2 that are generic and the most common properties, availability is made
a “property” in the wireless domain. With “2.3 Wireless Devices Implication”
in mind, this simply means that the wireless device shall be in full utility with the
protocol in place as it would have been without. On the design scale, the implication is
that the protocol shall not impose a load on the device so much as to reduce its
functionality.
2.5 Conventions and symbols used
As
is usual in most papers, we say that Alice and Bob are the parties, which communicate, and
Eve in the attacker in the middle. Further conventions and symbols shall be introduced as
and when the need arises.
3. Requirements of the Protocol
The section below now represents the
situation in which the protocol has to operate. The single line statement of the protocol
requirements is “To ensure the satisfaction of all the security properties in face of
such a situation”.
3.1 Communication Model
The
following communication model is assumed for the underlying layer. Alice and Bob
communicate over and insecure channel that, for all practical purposes shall be controlled
by Eve. Eve has at her disposal al the facilities that Alice and Bob posses.
3.1.1 Channel control: Eve can read all the
messages that pass through the channel (Messages in the sense of the underlying bits or
the information that is actually traversing the channel)
3.1.2 Message modification / Delay: Eve can modify the
messages traversing the channel or delay them by any time scale as is needed to subvert
any clock granularity that is in use.
3.1.3 Message generation: Eve can of course
generate and send any message to Alice and Bob as and when she wishes.
The primary
requirement of the protocol shall be to ensure secure and reliable communication in spite
of Eve having all the control(s) described above.
3.2 State of
Alice and Bob
3.2.1 Zero Knowledge Systems
Alice
and Bob shall have no knowledge of each other initially. This is not to say that Alice and
Bob do not know each other. They haven’t met before to have a shared secret between
them. (Note that this state is true only of 2 parties trying to communicate with each
other in the presence of a third part: this scenario mostly applies to two wireless users
communication with each other without knowing each others credentials)
3.2.2 Parallel Sessions
Alice
and Bob, as expected are mostly computers / devices. Eve shall be able to open multiple
sessions with both Alice and Bob simultaneously. Also, these multiple sessions of Alice
and Bob cannot communicate with each other. Eve shall be able to engage them into any
protocol conversation, with the possibility of using the information obtained in one
session in another. (Note that the actual protocol may not allow this, but it is required
of the protocol design that despite a possibility of multiple sessions, security concerns
are met)
3.3 Stand Alone Protocol Requirements
3.3.1 Other Protocol Interactions
Eve
shall be able to convince Alice and Bob to engage in other stand Alone safe protocols, in
as many sessions as is possible/required. This
raises the possibility of a chosen protocol attack. It is expected of the protocol to
withstand such attacks: A reference is given for the design principles for avoiding the
“chosen protocol attack”.
3.3.2 Perfect Forward Secrecy
This
simply means that the disclosure of a password does not in any way compromise or reveals
prior recorded conversations. This is a
requirement in the extreme case of an inadvertent password disclosure that may occur
beyond the protocol interactions. Hence the protocol is expected to ensure forward secrecy
i.e. the disclosure of a password shall not reveal previous conversations.
3.3.3 Password guessing Attacks
The
protocol shall protect itself from any password guessing attacks (Plain cipher text
attacks and offline guessing attacks). It shall also hopefully protect itself from
database exposure attacks (as in Lamports hash Algorithm), although it is recognized that
database exposure isn’t actually the function of the protocol itself strictly.
3.3.4 Transitivity of Trust
The
protocol shall not allow any transitivity of Trust. By Transitivity of Trust, it is meant
that a user can engage in a session with another user, but a third party has to go through
the normal process of a protocol interaction. The third party, on the basis of an
interaction with one of the two parties currently in a session shall not automatically
engage into a session with the other party in the established session.
3.3.5
Transient Security
This
is more in the context of the wireless devices mentioned before. It is required of the
protocol to enable all the security properties when the devices / users are intermittently
on and off. This is more in the context of saving power and recognizing the fact tat the
CPU power on the devices is limited. This assumes significance as the protocol can’t
assume a 10-message exchange for mutual authentication and later have the session expire
in 10 seconds.
5. Conclusion
The document has presented the requirements of
a security protocol to be used in lieu of a wireless network. This is a precursor to the
other requirements, specifications and design documents for the protocol and other issues
needed to make the entire wireless domain
