theft of service or denial-of-service attacks, where packets not
emitted by an authorized sender are accorded the QOS treatment
reserved for that sender (or for a group of which the sender is a
member). Thus, use of an LLID should be authenticated by routers
that make QOS decisions based on that LLID. (Note that not all
routers may "pay attention" to the LLID.)
In principle, the validity of an LLID assertion needs to be
checked on every packet, though not necessarily at every router;
it may be possible to restrict the checks to security perimeters.
At those routers that must validate LLIDs, there is an obvious
concern over the performance impact. Therefore, a router may
adopt a less rigorous approach to LLID validation. For example, a
router may elect to sample a data stream and validate some, but
not all, packets. It may also elect to forward packets first and
perform selective validation as a background activity. In the
least stringent approach, a router might log selected packets and
validate them as part of an audit activity much later.
There are several candidate techniques for validating the use of
LLIDs. We have identified three basic techniques, which differ in
terms of computational performance, bandwidth overhead, and
effectiveness (resistance to various forms of attack).
* Digital Signatures
The first technique entails the use of public key
cryptography and digital signatures. The sender of each
packet signs the packet (header and payload) by computing a
one-way hash over the packet and transforming the hash value
using a private key associated with the LLID. The resulting
authenticator value is included in the packet header. The
binding between the public key and the LLID is established
through a connection setup procedure that might make use of
public keys that enjoy a much longer lifetime. Using public
key technology yields the advantage that any router can
validate a packet, but no router is entrusted with data that
would enable it to generate a packet with a valid
authenticator (i.e., which would be viewed as valid by other
routers.) This characteristic makes this technique ideal
from the standpoint of the "principle of least privilege."
Public key cryptosystems such as RSA have the advantage that
validation of a signature is much faster than signing, which
reduces the router processing burden. Nonetheless, this
approach is not likely to be feasible for anything other than
selective checking by routers, given current public key
algorithm performance.
* Sealing
The next technique is based on the use of the same type of
one-way hash function used for digital signatures, but it
does not require signing the hash value. Here the sender
computes a one-way hash with a secret quantity (essentially a
"key") appended to the packet. This process is an example of
what is sometimes referred to more generically as
cryptographic "sealing." The inclusion of this key at the
end of the hash computation results in a hash value that is
not predictable by any entity not possessing the key. The
resulting hash value is the authenticator and is included in
the packet header. A router validates a packet by
recomputing the hash value over the received packet with the
same secret quantity appended. If the transmitted hash value
matches the recomputed hash value, the packet is declared
valid. Unlike the signature technique, sealing implies that
all routers capable of verifying a seal are also capable of
generating (forging) a seal. Thus, this technique requires
that the sender trust the routers not to misuse the key.
This technique has been described in terms of a single secret
key shared between the sender and all the routers that need
to validate packets associated with an LLID. A related
alternative strategy uses the same authenticator technique,
but shares the secret key on a pairwise basis, e.g., between
the sender and the first router, between the first router and
the next, etc. This avoids the need to distribute the secret
key among a large group of routers, but it requires that the
setup mechanism enable Router A to convince his neighbor
(Router B) that Router A is authorized to represent traffic
on a specific LLID or set of LLIDs. This might best be done
by encapsulating the packet inside a wrapper that both ends
of the link can validate. Once this strategy is in place, it
may even be most efficient for routers to aggregate traffic
between them, providing authentication not on a per-LLID
basis, since the router pairs are prepared to "trust" one
another to accurately represent the data stream LLIDs.
For a unicast data stream, the use of pairwise keying between
routers does not represent a real change in the trust
required of the routers or of the setup mechanism, because of
the symmetric sharing of the secret key. However, for a
multicast connection, this pairwise keying approach is
superior in that it prevents a router at one point in a
multicast tree from being able to generate traffic that could
be inserted at another point in the tree. At worst, a router
can generate spurious, but authenticatable, traffic only for
routers "below" it in the multicast tree.
Note that the use of network management fault isolation
techniques, e.g., sampling router traffic statistics at
different points along a data stream, should permit post hoc
detection of packet forgery attacks mounted by rogue routers
along a data stream path. Use of this technique could
provide a deterrent to such activity by routers, further
arguing for the pairwise keying approach.
The sealing technique is faster than the digital signature
technique, because the incremental hash calculation
(including the appended secret quantity) is much faster than
the cryptographic transformation required to sign a hash.
The processing burden is symmetric here, i.e., the sender and
each router devote the same amount of processing power to
seal a packet and to verify the seal. Also, a sealed hash
may be smaller than a signed hash, even if the same function
is used in both cases. (This is because the modulus size of
the public key signature algorithm and any ancillary
parameters tend to increase the size of the signed hash
value.) Moreover, one could use a hash function with a
"wide" value and truncate that value, if necessary to reduce
overhead; this option is not available when the authenticator
is a signed hash value.
As a variant on this technique, one could imagine a
"clearinghouse" that would receive, from the sender, the
secret key used to generate and validate authenticators. A
router needing to validate a packet would send a copy of the
packet to the clearinghouse, which would check the packet and
indicate to the router whether it was a valid packet
associated with the LLID in question. Obviously, this
variant is viable only if the router is performing
infrequent, selective packet validation. However, it does
avoid the need to share the authenticator secret among all
the routers that must validate packets.
For both of these techniques, there is a residual
vulnerability to denial-of-service attacks based on replay of
valid packets during the lifetime of a data stream. Unless
packets carry sequence numbers and routers track a sequence
number window for each data stream, an (external) attacker
can copy valid packets and replay them. It may be easiest to
protect against this form of attack by aggregating all
traffic between a pair of routers into a single flow and
providing replay protection for the flow as a whole, rather
than on a per data stream basis.
* Temporary Passwords
The final technique explored in the workshop takes a very
different tack to packet validation. The preceding
techniques compute a function of the bits in a packet and
transform that value in a fashion that prevents an intruder
from generating packets with valid authenticators. The
ability to generate packets with valid authenticators for a
given LLID requires access to a secret value that is
available only to the sender, or to the sender and to routers
participating in a given data stream.
In contrast, this third technique calls for the authenticator
to be a short term, secret quantity that is carried in the
packet header, without benefit of further protection. In
essence, this technique incorporates a short term "password"
into each packet header. This approach, like its
predecessor, requires that all of the routers validating the
LLID be privy to this authenticator. Moreover, the
authenticator is visible to any other router or other
equipment along the path, and thus this technique is much
more vulnerable than the previous ones.
Here the same authenticator may be applied to all packets
with the same LLID, since the authenticator is not a function
of the packet it authenticates. In fact, this suggests that
it is feasible to use the LLID as the authenticator.
However, adopting this tack would not be consistent with the
two previous techniques, each of which requires an explicit,
separate authenticator, and so we recommend against this
optimization.
Nonetheless, the fact that the authenticator is independent
of the packet context makes it trivial to generate (forge)
apparently authentic packets if the authenticator is
intercepted from any legitimate packet. Also, if the
authenticator can be guessed, an attacker need not even
engage in passive wiretapping to defeat this scheme. This
latter observation suggests that the authenticator must be of
sufficient size to make guessing unlikely, and making the
LLID and the authenticator separate further supports this
requirement.
The major advantage of this approach is one of performance.
The authenticator can be validated very quickly through a
simple comparison. Consistent with the need to protect
against guessing attacks, the authenticator need not consume
a significant amount of space in the packet header.
The use of a sequence number visible to the routers is an
interesting technique to explore to make these somewhat
vulnerable methods more robust. If each stream (each source
of packets) numbers its packets, then an intruder attempting
to use the network resource must delete the legitimate
packets, which in many cases would be difficult. Otherwise,
the router being attacked would notice duplicate sequence
numbers and similar anomalies. The exact details of the
numbering would have to be worked out, since for the
legitimate stream packets might be lost, which would cause
holes in the sequence space.
We do not consider here the issues of collusion, in which a user
with a given LLID and authenticator deliberately shares this with
another unauthorized user. This possibility should be explored,
to see if there is a practical advantage to this act, and thus a
real threat.
4.4 Dynamics of Setup
o Duration of LLID's
A key question in the use of LLIDs is how long they remain
valid. At one extreme, they last only a very short time,
perhaps seconds. This limits the damage that can be done if
the authenticator for the LLID is stolen. At the other
extreme, LLIDs are semi-permanent, like credit card numbers.
The techniques proposed above for securing the LLID traded
strength for efficiency, under the assumption that the peril
was limited by the limited validity of the LLID.
The counterbalancing advantage of long-term or semi-permanent
LLIDs is that it becomes practical to use primitive setup
techniques, such as manual configuration of routers to
establish packet classes. This will be important in the
short run, since deployment of security and dynamic resource
allocation protocols may not exactly track in time.
We conclude that the correct short-term action is to design
LLIDs under the assumption that they are fairly short lived,
and to tolerate, in the short run, a longer period of
validity. This would imply that we will get an acceptable
long-term mechanism in place, which operationally will have a
lower level of security at first. As we get better tools for
automatic setup, we can shorten the duration of validity on a
individual basis, without replacing mechanism in the packet
forwarding path.
o Setup Latency
The tradition of the Internet is not to impose any setup
latency in the communication path between end nodes. This
supports the classic datagram model for quick transactions,
etc., and it is a feature that should be preserved.
For setup that is done "in advance", either through a
management interface or by an end-node in the background, the
issue of latency does not arise. The latency issue occurs
for dynamic reservations made in response to a specific
application request.
We observe that while latency is a key issue, it is not
materially influenced by security concerns. The designers of
resource reservation protocols such as RSVP and ST-II are
debating the latency of these protocols today, absent
security. Adding an authenticator to the request message
will increase the processing needed to validate the request,
and might even imply a message exchange with an
authentication service, but should not substantially change
the real time of the setup stage, which might already take
time on the order of a round-trip delay. But the design of
the high level authentication and authorization methods for
the setup protocol should understand that this process, while
not demanding at the level of the per-packet processing, is
still somewhat time-critical.
One way of dealing with an expensive setup process is to set
up the request provisionally and perform the validation in
the background. This would limit the damage from one bad
setup request to a short period of time. Note, however, that
the system is still vulnerable to an attack that uses a
sequence of setup requests, each of which allows unauthorized
usage for at least a short period of time.
Note also that a denial-of-service attack can be mounted by
flooding the setup process with invalid setup requests, all
of which need to be processed and rejected. This could
prevent a valid user from setting up any state. However,
denial-of-service attacks based upon flooding leave very
large "finger prints"; they should not normally be an
important threat. If it is a problem, it may be possible to
incorporate a mechanism at the level of setup processing that
is equivalent to "fair queueing", to limits the damage from a
flooding attack at the packet level.
4.5 Receiver-Initiated Setup
Recent work on a QOS extension for the Internet, embodied in the
RSVP protocol, uses the model that the receiver will reserve
resources. This scheme is consistent with the current IP
multicast paradigm, which requires the receiver to join the
multicast group. The receiver reserves the resources to insure
that the multicast traffic reaches the receiver with the desired
QOS. In this case, it is the credentials (the HLIDs) of the
receivers that will be presented to the setup phase.
Note that receiver initiation requires an explicit setup phase.
Suppose setup were implicit, driven by pre-existing fields in the
packet. Then there would be no way to associate a packet with a
particular receiver, since in multicast, the address of the
receiver never appears in the packet.
Further, it is impossible in this case to perform a setup "in
advance", unless the sender and the receiver are very tightly co-
ordinated; otherwise, the receiver will not know in advance what
LLID will be in the packet. It is certainly impossible, in this
case, for the receiver to set up "semi-permanent" reservations for
multicast traffic coming to it. This, again, is not a security
issue; the problem exists without adding security concerns, but
the security architecture must take it into account.
4.6 Other Issues
4.6.1 Encrypting Firewalls and Bypass
Our view of security, both end node and network protection,
includes the use of firewalls, which partition the network into
regions of more or less trust. This idea has something in
common with the encrypting-firewall model used in the
military/intelligence community: red (trusted) networks
partitioned from black (untrusted) networks. The very
significant difference is that, in the military model, the
partition uses an encryption unit that encodes as much as
possible of the packet for its trip across the black network to
another red network. That is, the purpose of the encryption
unit, among others, is to provide a very high degree of
protection against disclosure for data housed within the red
networks. In contrast, our version of a firewall is more to
protect the trusted (red) region of the network from outside
attacks. It is concerned both with what comes in and with what
goes out. It does permit communication between a node on the
trusted and nodes in the untrusted parts of the network.
We would like to be able to adapt our model of secure QOS to
the case of military-style encrypting firewalls. However, this
use of encryption raises a problem with our model of secure
resource management, discussed above, which was based on a
two-stage process of setup and classification. This model is
problematic because it requires information to pass from the
red region to the black region in the clear. This information
includes both the setup packets themselves, if setup is done
dynamically from the end node, and the classification fields
(the LLIDs) in the data packets. Obviously, this information
cannot be encrypted when leaving the red region of the network,
since it would then be meaningless to the black net, so that
the black network would be unable to make resource allocation
decisions based on it.
To make this sort of control scheme work, it is necessary for
the encryption device to be programmed to permit certain
packets and fields in packets to pass through the encryptor in
the clear. This bypass of the encryption is considered highly
undesirable. In a high security situation, the process
generating the bypassing information might be corrupted, with
the result that information that should be controlled is
removed from the secure network by hiding it in the bypassed
fields of the packets.
We concluded, however, that this bypass problem is not
insurmountable. The key idea, as in all cases of bypass, is to
limit, rather than wholly outlaw, the information passing in
the clear. To limit the information needed for bypass, one can
either perform the setup as a management function totally
within the black environment, or divide the process into two
stages. The first stage, again totally in the black context,
defines a limited number of setup situations. The second stage
involves sending from the red net a very small message that
selects one request to be instantiated from among the pre-
defined set.
Perhaps the more difficult issue is the LLID in the packet
header. If the LLID is an explicit field (as we have discussed
so far, but see below), it represents a new field in each
packet, with perhaps as many as 32 bits. Again, the solution
is to limit the way this field can be used. When the end-node
performs a setup, it will specify the value of the LLID to be
used. This fact can be observed by the red/black encryption
unit, which can then limit the components of this field to the
values currently in use. To further improve the situation, the
encryption unit might be able to aggregate a number of flows
onto one flow for the purpose of crossing the black net, which
would permit a further reduction in the number of distinct
LLIDs that must escape the red region.
The details of this proposal, including some important issues
such as the time duration of LLIDs in this case, must be
considered further. However, the initial conclusion that
bypass can be incorporated into a general resource control
framework is very encouraging, since it suggests that both
military and commercial forms of security can be built out of
the same building blocks.
4.6.2 The Principle of Consistent Privilege
A well understood principle of security is the principle of
least privilege, which states that a system is most robust when
it is structured to demand the least privilege from its
components.
A related rule we observe is the principle of consistent
privilege. This can be illustrated simply in the case of
denial of service, where it is particularly relevant. For a
particular route, no assumption of service can be justified
unless we trust the routers to deliver the packets. If a
router is corrupted and will not forward packets, the only
solution is to find another route not involving this router.
We do not concern ourselves here with protocols for finding new
routes in the presence of a corrupted router, since this topic
is properly part of another topic, securing the network
infrastructure. We only observe that either we will get
service from the router or we will not. If the router is
corrupted, it does not matter how it chooses to attack us.
Thus, as long as the router is part of a forwarding path (most
generally a multicast forwarding tree), we should not hesitate
to trust it in other ways, such as by giving it shared resource
keys or LLID verifiers.
This illustrates the principle of consistent privilege. This
principle is exploited in the scheme for hop-by-hop or pairwise
use of secrets to validate LLIDs in a multicast tree. If a
single key is issued for the whole tree, then the privilege is
not consistent. We only need to trust a router with respect to
the nodes "below" it in the tree. If it fails to forward
traffic, it can affect only those nodes. But if we give it the
group key, then it can generate bogus traffic and inject it
into the tree at any point, affecting traffic for other parts
of the tree. If, on the other hand, we use pairwise keys, then
a corrupt node can only generate bogus traffic with the key for
traffic it would directly receive, which is the part of the
tree it could damage anyway.
Another requirement we must place on the network concerns
routing. If a firewall is in place, we must trust the routing
architecture not to bypass that firewall. One way to
accomplish this is to eliminate any physical path between the
regions other than those that go through the firewall.
Operational experience will be required to see if this simple
physical limit is an acceptable constraint.
4.6.3 Implicit LLID's
We stress the importance of a strong conceptual distinction
between the addresses in a packet and the LLID which is used to
classify the packet. The conceptual distinction is important,
but under limited circumstances it may be possible to overload
some of the packet fields and create an LLID from the current
packet header. For example, current packet classifiers for
IPv4, which are not secure but which seem to work for
classifying the packets into service classes, use a number of
the packet fields together as a form of LLID: the source and
destination IP addresses and ports plus the protocol type.
This sort of "implicit" LLID must be short-lived, especially if
the host can change its IP address as it moves. But if the
LLID is established by some sort of dynamic setup protocol, it
should be possible reestablish the LLID as needed.
The current IPv4 header has no authenticator field to validate
the LLID. An authenticator field could be optionally carried
in an option; adding it gives robustness to network
reservations. Any of the schemes described above for creating
an authenticator could be used, except that if the simple
password-style authenticator is used, it must be an explicit
separate field, since the LLID cannot be picked randomly.
4.6.4 Security without Setup
As we describe this architecture, the setup phase is an
essential part of the sequence. This suggests that the current
Internet, which has no setup protocols, cannot be secured
against denial-of-service attacks. It is important to explore
the limits of this point. As we stressed above, setup can
occur in many ways. Routers today offer management options to
classify packets based on protocol types and other fields found
in the header, and to use this classification to create a few
fair queueing classes that can prevent one class from
overloading the net to the exclusion of the others.
There are two problem here. The first is that for a setup done
using a management interface, the secret that is shared among
the source and the routers to validate the LLID must remain
valid for a long time, and it must be manually configured. The
second problem is that the granularity of the categories may be
coarse. However, it has been proposed, in a thesis by Radia
Perlman, that a router might create a separate fair queueing
class implicitly for each source address. This approach, which
uses the addresses as an implicit LLID, must have some form of
authenticator for robustness. But if the LLID can be trusted,
this scheme provides classification of traffic based only on an
implicit setup operation. The granularity of classification is
not sufficient to provide any QOS distinction. The only
objective is to prevent the traffic from one source from
flooding the net to the exclusion of another.
4.6.5 Validating Addresses
We make a claim here that if the LLID and the addresses in the
packet are conceptually distinct, and if there is a suitable
means to validate the LLID, then there is no reason to validate
the addresses. For example, a packet constructed with a false
source address does not seem to represent any security problem,
if its LLID can be validated.
An exception to this might possibly lie in communication with
mobile hosts, but it will require a complete model of threats
and requirements in the mobile environment to be sure.
However, we make the claim, as a starting point for discussion,
that if LLIDs are distinguished from addresses, many of the
security concerns with mobility are mitigated and perhaps
removed. This point should be validated by more detailed
consideration of the mobility problem.
4.6 Conclusions
a) It is important to conceptually separate a LLID (Low-Level
IDentifier) carried in a packet from addresses in the packet.
b) There will be a single LLID carried in each packet. Although
this might imply some additional state in the routers than if
multiple LLIDs were used, using only one LLID choice is more
scalable.
c) Hop-by-hop LLID authentication mechanisms might provide a
highly scalable approach that limits the distribution of
secrets. However, the robustness limitations must be
investigated thoroughly.
d) Statistical sampling or after-the-fact detection mechanisms
may be employed by routers to address performance concerns.
5. AN AUTHENTICATION SERVICE
The purpose of an authentication service is simply to verify names,
or more precisely to verify the origin of "messages". It differs
from the authorization service, which determines what services are
available to an authenticated name. We expect that authentication
will be an Internet-wide service, while authorization will be
specific to the resources to which access is being authorized.
This "identification" function can be used in several contexts, for
example:
* One-time passwords: "it is really <huitema@inria.fr> that is
responding to this challenge".
* Access to a firewall: "it is really <huitema@inria.fr> that is
trying to send data to host-A at port-a".
There are many Internet objects that we may want to name, e.g.,:
domain names: sophia.inria.fr
machine names: jupiter.inria.fr
service names: www.sophia.inria.fr
(in fact, a data base)
users: huitema@sophia.inria.fr
processes: p112.huitema@sophia.inria.fr
p112.sophia.inria.fr
universal resource locators:
http//www.sophia.inria.fr:222/tmp/foobar
One could be tempted to believe that the authentication service will
only be concerned with naming humans, as only humans are
"responsible"; a process obtains some access rights because it is
acting on behalf of a person. However, this is too reductive and
potentially misleading. We may have to authenticate "machines" or
hardware components. For example:
* When a machine boots it needs to access resources for
configuring itself, but it is not yet "used" by a person; there
is no user.
* On a "distributed processor", component CPUs may need to
authenticate each other.
Machines do differ from users; machines cannot keep their "secrets"
in the same way that people do. However, there is a big value in
having a simple and extensible name space.
5.1 Names and Credentials
We make the hypothesis that the authorization services will
generally use "access control lists" (ACLs), i.e., some definition
of a set of authorized users. A compact way to represent such a
set would be to allow "wildcard" authorizations, e.g., "anybody at
<Bellcore.com>", or "any machine at <INRIA.FR>". The
authentication service should be designed to facilitate the
realization of the authorization service and should support
"wildcards".
However, wildcards are not general enough. Assuming that we have
a hierarchical name space, a wildcarded entry is limited to the
naming hierarchy. For example, a name like
<huitema@sophia.inria.fr> could be matched by the wildcard
<*@sophia.inria.fr> or <*.inria.fr> or <*.fr>. This is useful as
long as one stays at INRIA, but does not solve the generic
problem. Suppose that an IETF file server at CNRI is to be
accessible by all IAB members: its ACL will explicitly list the
members by name.
The classic approach to naming, as exemplified in the X.500 model,
is to consider that people have "distinguished names". Once one
has discovered such a name through some "white pages" service, can
use it as an access key in a global directory service.
An individual may acquire authorizations from a variety of
sources. Using a pure, identity-based access control system, the
user would have to acquire multiple identities (i.e.,
distinguished names), corresponding to the roles in which she is
authorized to access different services. We discuss this approach
in the next section.
An alternative approach is for the user to have a very small
number of identities, and to have the grantors of authorizations
issue (signed) credentials granting permissions to the user,
linked to her ID. These additional signed credentials are known
as "capabilities". The user can then establish her identity
through a generic identity credential, e.g., an X.509 certificate,
and can establish authorization by presenting capabilities as
required. This is somewhat analogous to a person acquiring credit
cards linked to the name on a driver's license, and presenting the
appropriate credit card, plus the license for picture verification
of identity.
5.2 Identity-Based Authorization
Let's open the wallet of an average person: we find several
"credit cards" in it. We all have many "credit cards", e.g.,
company cards, credit cards, airline frequent flyers memberships,
driver licenses. Each of these cards is in fact a token asserting
the existence of a relation: the bank certifies that checks
presented by the bearer will be paid, the traffic authorities
certifies that the bearer has learned how to drive, etc. This is
an example of identity-based authorization, in which an individual
is given different names corresponding to different relations
entered into by that individual.
If we imagine that the name space is based upon DNS (domain)
names, then for example, the person mentioned above could be
authenticated with the names:
customer@my-big-bank.com
customer@frequent-flyer.airline.com
The model we used here is that "the name is an association". This
is consistent with name verification procedures, in which that one
builds a "chain of trust" between the user and the "resource
agent". By following a particular path in the trust graph, one
can both establish the trust and show that the user belongs to an
"authorized group".
The existence of "multiple names" for a person may or may not
imply the existence of an "equivalence" relation. It may be
useful to know that <huitema@sophia.inria.fr> and
<huitema@iab.isoc.org> are two names for the same person, but
there are many cases where the user does not want to make all his
tokens visible.
5.3 Choosing Credentials
Let's consider again the example of Christian Huitema accessing a
file at CNRI. He will have to interact with INRIA's outgoing
firewall and with CNRI's incoming controls. Regardless of whether
authorization depends upon capabilities or upon multiple
association names, a different credential may be needed in each
firewall on the path. For example, assuming multiple names are
used, he will use an INRIA name, <huitema@sophia.inria.fr>, to be
authorized by INRIA to use network resources, and he will use an
IAB name, <huitema@iab.isoc.org>, to access the file server. Thus
comes an obvious problem: how does he choose the credential
appropriate to a particular firewall? More precisely, how does
the computer program that manages the connection discover that it
should use one credential in response to INRIA's firewall
challenge and another in response to CNRI's request?
There are many possible answers. The program could simply pass
all the user's credentials and let the remote machine pick one.
This works, but poses some efficiency problems: passing all
possible names is bulky, looking through many names is long.
Advertising many names is also very undesirable for privacy and
security reasons: one does not want remote servers to collect
statistics on all the credentials that a particular user may have.
Another possibility is to let the agent that requests an
authorization pass the set of credentials that it is willing to
accept, e.g., "I am ready to serve CNRI employees and IAB
members". This poses the same privacy and security problems as
the previous solutions, although to a lesser degree. In fact, the
problem of choosing a name is the same as the generic "trust path"
model. The name to choose is merely a path in the authentication
graph, and network specialists are expected to know how to find
paths in graphs.
In the short term, it is probably possible to use a "default name"
or "principal name", at least for local transactions, and to count
on the user to "guess" the credential that is required by remote
services. To leave the local environment we need only the local
credentials; to contact a remote server we need only the
destination credentials. So we need one or maybe two credentials,
which may be derived from the destination. It will be very often
the case that the generic credential is enough; then wildcards;
then "FTP provided" tokens.
6. OTHER ISSUES
6.1 Privacy and Authentication of Multicast Groups
Multicast applications are becoming an increasingly important part
of Internet communications. Packet voice, video and shared
whiteboard can be powerful productivity tools for users. For
these applications to have maximum value to their users, a variety
of security services will be required.
Existing techniques are directly applicable to providing privacy
for a private teleconference. If each member of the conference
shares a single key for a symmetric encryption algorithm (such as
DES), existing point-to-point security techniques can be extended
to protect communication within the group from outsiders.
However, slight modifications to existing techniques are required
to accommodate the multicast environment. Each packet will
require independent cryptographic processing to ensure that
packets from multiple sources can be independently decrypted by
the numerous receivers, particularly in the presence of lost
packets. N-party authentication and key management will be
required to establish the shared key among the proper group
members. This can be done by extending existing two-party key
management techniques pairwise. For example, the conference
manager may provide the key to each member following individual
authentication; for example, this could be implemented trivially
using PEM technology. The overhead experienced by each host
computer in the conference will be similar to that of existing
point-to-point encryption applications, This overhead is be low
enough that, today, software encryption can offer adequate
performance to secure whiteboard and voice traffic, while hardware
encryption is adequate for video.
The nature of multicast communication adds an additional
requirement. Existing multicast conferences provide gradual
degradation in quality as the packet loss rate increases. To be
acceptable, authentication protocols must tolerate lost packets.
Techniques to accomplish this efficiently need to be developed.
One initial sketch is outlined below. Engineering work will be
required to validate the practicality of this approach.
The use of symmetric encryption provides the members of the
conference with effective protection from outsiders. However,
because all members of the conference share a single key, it does
not provide a means of authenticating individual conference
members. In principle, existing techniques, based on one-way hash
functions coupled with digital signatures based on asymmetric
encryption algorithms, can provide individual authentication.
One-way hash functions such as MD5 are comparable in cost to
symmetric encryption. However, digital signatures are
considerably more costly, both in computation and in communication
size. The degree of overhead depends on the quality of
authentication required.
In summary, realtime authentication at the granularity of group
membership is easy and cheap, but individual authentication is
costly in time and space. Over time, the costs of both
communications and processing are expected to decline. It is
possible that this will help make authentication at the level of
individual conference participants. There are two conflicting
trends: (1) increasing CPU speeds to provide symmetric
encryption, and (2) increasing communication data rates. If both
technologies increase proportionally, there will be no net gain,
at least if the grain size is measured in terms of bits, rather
than as a period in seconds.
The group felt that the correct approach to end-to-end controls is
the use of encryption, as discussed above. The alternative is to
control the ability of a user to join a multicast group as a
listener, or as a speaker. However, we are not comfortable with
the level of assurance that we can offer if we attempt to ensure
end-to-end semantics using these means. Any passive penetration
of the network, i.e., any wire-tap, can compromise the privacy of
the transmitted information. We must acknowledge, however, that
problems with deployment of encryption code and hardware, and
especially problems of export controls, will create a pressure to
use the tools described in Section 4 to implement a form of end-
to-end control. Such a decision would raise no new issues in
security technology. The shared key now used for encrypting the
data could instead be used as the basis for authenticating a
multicast group join request. This would require modification of
the multicast packet format, but nothing more. Our concern is not
the technical difficulty of this approach, but the level of
assurance we can offer the user.
6.2 Secure Plug-and-Play a Must
Plug-and-play is the ability to plug a new device into a network
and have it obtain the information it needs to communicate with
other devices, without requiring any new configuration
information. Secure plug-and-play is an important Internet
requirement, and a central architectural issue is whether it can
be made to scale well.
For plug-and-play operation, a new machine that is "plugged" into
the network needs to:
(1) Obtain an locator so it can communicate with other devices
(2) Register or obtain a name to be identified by (e.g., machine
name)
(3) Discover services available on the network (e.g., printers,
routers, file servers, etc.)
(4) Discover other systems on the network so it can communicate
with them.
In some environments, no security mechanisms are required because
physical security and local knowledge of the users are sufficient
protection. At the other end of the spectrum is a large network
with many groups of users, different types of outside connections,
and levels of administrative control. In such environments,
similar plug-and-play capabilities are needed, but the new device
must be "authenticated" before it can perform these functions. In
each step in the discovery process the new device must
authenticate itself prior to learning about services.
The steps might be:
- Obtain a HLID from a smart card, smart disk, or similar
device.
- Authenticate itself with the first plug-and-play server using
its HLID, to register a name and to find the location of
other services.
- Discover services available on the network (e.g., printers,
routers, file servers, etc.) based on its HLID.
- Discover other systems on the network so it can communicate
with them.
The problem of taking a system out of the box and initially
configuring it is similar to the problem of a mobile or portable
machine that a human wants to connect to a local network
temporarily in order to receive services on that network. How can
the local network authenticate the human (and therefore the
human's machine) and know which services this visiting machine is
permitted to use?
The human must be endowed with a high level identifier (HLID)
which acts as his/her passport and can be verified by the local
network. This high level identifier must be globally unique and
registered/assigned by some recognized authority.
When the human plugs the machine onto a local net, the machine
identifies itself to the net with the human's high level
identifier. If local net has a policy of permitting anyone to
plug and play on its network, it will ignore the HLID and assign
an address (locator), permitting the visitor unrestricted access
and privileges. More likely, the local net will authenticate the
HLID prior to granting the visitor an address or any privileges.
At this point, the HLID has only authenticated the visitor to the
local network; the issue of which services or resources the
visitor is entitled to use has not been addressed. It is
desirable to develop a low-overhead approach to granting
authentications to new users. This will help in the case of
visitors to a site, as well as new users joining a facility.
6.3 A Short-Term Confidentiality Mechanism
Authentication has customarily been achieved using passwords. In
the absence of active attacks, the greatest threat to computer
system security may be the ease with which passwords can be
"snooped" by the promiscuous monitoring of shared-media networks.
There are known security techniques for achieving authentication
without exposing passwords to interception, for example the
techniques implemented in the well-known Kerberos system.
However, authentication systems such as Kerberos currently operate
only in isolation within organizational boundaries. Developing
and deploying a global authentication infrastructure is an
important objective, but it will take some years. Another useful
approach in the short term is the use of a challenge-response user
authentication scheme (e.g., S/Key).
One of the groups explored another interim approach to guarding
passwords: introducing a readily-used confidentiality mechanism
based on an encrypted TCP connection. This would operate at the
IP level to encrypt the IP payload, including the TCP header, to
allow the nature as well of the contents of the communication to
be kept private. It could be implemented to provide either
"strict" protection (the connection fails if the other side cannot
decrypt your data stream) or "loose" protection (falling back to
non-private TCP if decryption fails).
Loose protection would allow interoperability with older hosts in
a seamless (non-user-intrusive) manner.
One-time keys may be exchanged during the SYN handshake that
starts the TCP connection. Using one-time keys avoids a need for
infrastructure support and does not require trust between the
organizations on the two ends of the connection. Tieing the key
exchange to the SYN handshake will avoid the possibility of having
the connection fully open without knowing the state of encryption
on both ends of the connection. Although it may still be
theoretically possible to intercept the SYN exchange and subvert
the connection by an active "man-in-the-middle" attack, in
practice such attacks on TCP connections are quite difficult
unless the routing protocols have been subverted.
The keys could be exchanged using a new option that specifies the
key exchange protocol, the data encryption algorithm, and the key
to be used to decrypt the connection. It could be possible to
include multiple options in the same SYN segment, specifying
different encryption models; the far end would then need to
acknowledge the option that it is willing to use. In this case,
the lack of an acknowledgement would imply disinterest in
decrypting the datastream. If a loose privacy policy were in
force, the connection could continue even without an
acknowledgment. The policy, "strict" or "loose", would be set by
either the user or the default configuration for the machine.
One must however observe that a TCP option can carry only a
limited amount of data. Efficient protection against crypto-
analysis of the Diffie-Hellmann scheme may require the use of a
very long modulus, e.g., 1024 bits, which cannot be carried in the
40 bytes available for TCP options. One would thus have either to
define an "extended option" format or to implement encryption in a
separate protocol layered between TCP and IP, perhaps using a
version of "IP security". The detailed engineering of such a
solution would have to be studied by a working group.
A TCP connection encryption mechanism such as that just outlined
requires no application changes, although it does require kernel
changes. It has important drawbacks, including failure to provide
privacy for privacy for UDP, and the great likelihood of export
control restrictions. If Diffie-Hellman were used, there would
also be patent issues.
7. CONCLUSIONS
As a practical matter, security must be added to the Internet
incrementally. For example, a scheme that requires, as a
precondition for any improvement, changes to application code, the
DNS, routers and firewalls all at once will be very hard to deploy.
One of the reasons the workshop explored schemes that are local to
the IP layer is that we surmise that they might be easier to deploy
in practice.
There are two competing observations that must shape planning for
Internet security. One is the well known expression: "the best is
the enemy of the good." The other is the observation that the