Trust Management and Network Layer Security Protocols

TLDR: Key management in network-layer security among mutually trusting hosts is similarly straightforward in the simplest case, and two hosts can use any key-agreement protocol to negotiate keys with one another, and simply use those keys as part of the encapsulating and decapsulating packet transforms.

Abstract: Network-layer security among mutually trusting hosts is a relatively straightforward problem to solve. The standard protocol technique, employed in IPSEC [KA98], involves “encapsulating” an encrypted network-layer packet inside a standard network packet, making the encryption transparent to intermediate nodes that must process packet headers for routing, etc. Outgoing packets are authenticated, encrypted, and encapsulated just before being sent to the network, and incoming packets are decapsulated, verified, and decrypted immediately upon receipt [IB93]. Key management in such a protocol is similarly straightforward in the simplest case. Two hosts can use any key-agreement protocol to negotiate keys with one another, and simply use those keys as part of the encapsulating and decapsulating packet transforms.

Full text

Trust Management and Network Layer Security
Proto cols
Matt Blaze
1
and John Ioannidis
1
and Angelos D. Keromytis
2
1
AT&T Laboratories { Research
f
mab,ji
g
@research.att.com
2
Distributed Systems Labs
CIS Department, UniversityofPennsylvania
angelos@dsl.cis.upenn.edu
1 Intro duction
Network-layer security among mutually trusting hosts is a relatively straightfor-
ward problem to solve. The standard protocol technique, employed in IPSEC
[KA98], involves \encapsulating" an encrypted network-layer packet inside a
standard network packet, making the encryption transparent to intermediate
nodes that must process packet headers for routing,
etc.
Outgoing packets are au-
thenticated, encrypted, and encapsulated just b efore being sent to the network,
and incoming packets are decapsulated, veried, and decrypted immediately
upon receipt[IB93]. Key management in such a proto col is similarly straight-
forward in the simplest case. Two hosts can use any key-agreement protocol
to negotiate keys with one another, and simply use those keys as part of the
encapsulating and decapsulating packet transforms.
In many applications, security at the network later has a numb er of advan-
tages over security provided elsewhere in the proto col stack. Network semantics
are usually hidden from applications, which therefore automatically and trans-
parently take advantage of whatever network-layer security services their envi-
ronment provides. Especially importantly, the network layer oers a remarkable
exibility not p ossible at higher- or lower- abstractions: security can b e cong-
ured end-to-end (protecting trac b etween two hosts), route-to-route (protect-
ing trac passing over a particular set of links), edge-to-edge (protecting trac
as it passes between \trusted" networks via an \untrusted" one), or in any other
conguration in which network nodes can be identied as appropriate security
endpoints.
Fortunately, the design of encapsulation techniques for basic authentication
and condentiality services is not a conceptually dicult problem, and network-
layer security proto cols, such as IPSEC, have matured to the point of b eing
standardized and implemented by commercial vendors.
A harder problem, however, and one that current standards for network-layer
security do not address, is the management of the p olicy governing the handling
of packets on the wayinto or out of a host running the encapsulation proto-
col. By itself, the security protocol protects packets from external tamp ering
and eavesdropping, but do es nothing to enforce a policy as to which hosts are

authorized to exchange particular kinds of trac. In many congurations, espe-
cially when network-layer security is used to build rewalls and virtual private
networks, such polices can be quite complex.
Central to the problem of engineering p olicy mechanisms for network security
is the tradeo between expressiveness and performance. Unfortunately, many
congurations demand a high level of both.
In this position pap er, we examine the problem of managing policy in net-
work-layer security protocols, and propose a trust-management architecture for
network-layer security that may satisfy b oth the expressibility and the p erfor-
mance issues.
2 IPSEC Policy Architecture
Let us examine the architecture of network-layer security more closely, using
IPSEC as a sp ecic example. In this environment, policy must b e enforced when-
ever packets arrive at or are ab out to leave a network security endpoint (which
could be an end host, a gateway, a router, or a rewall).
When an incoming packet arrives from the network, the security endp oint
rst determines the processing it requires:
{
If the packet is not protected, should it be accepted? This is essentially
the \traditional" packet ltering problem, as performed,
e.g.,
by network
rewalls.
{
If the packet was encapsulated under the security protocol:

Is there correct key material (usually contained in a data structure called
a \security association") required to decapsulate it?

Should the resulting packet (after decapsulation) b e accepted? A second
stage of packet ltering o ccurs at this point. Notice that a packet may
be successfully decapsulated and still not be accepted (
e.g.,
a decapsu-
lated packet might contain an illegal network source IP address suchas
127.0.0.1).
A security endp oint makes similar decisions when an outgoing packet is ready
to be sent:
{
Is there a security asso ciation (SA) that should b e applied to this packet? If
there are several applicable SAs, which one should be selected?
{
If there is no SA available, how should the packet be handled? It may be
forwarded to some network interface, dropp ed, or queued until an SA is
made available, p ossibly after triggering some automated key management
mechanism such as the IPSEC ISAKMP proto col[HC98].
Observe that because these questions are asked on packet-by-packet basis,
policy ltering must be performed, and any related security transforms applied,
quickly enough to keep up with network data rates. This implies that in all but
the slowest network environments there is insucient time to process elaborate

security languages, p erform public key operations, consult large tables, or resolve
rule conicts in any sophisticated manner.
Implementations of network layer security services, including IPSEC and
most rewalls, therefore, usually employvery simple, lter-based languages for
conguring their packet-handling policies. In general, these languages sp ecify
routing rules for handling packets that match bit patterns in packet headers,
based on such parameters as incoming and outgoing addresses and ports, ser-
vices, packet options,
etc.
[MJ93]
However, packet-level ltering { necessary as it might b e { is not the inter-
esting problem.
3 Policy and Security Asso ciations
A basic parameter of the packet processing problems mentioned in the previous
section is the question of whether a packet falls under the scop e of some Security
Association (SA). SAs contain and manage the key material required to p erform
network-layer security protocol transforms. How then, do SAs get created?
The obvious approachinvolves the use of a public-key or Needham-Schroeder
[NS78] based key distribution scheme as the basis for a protocol that creates a
new SA with whatever host attempts to communicate unsecured trac in a man-
ner that fails the packet-level security policy.At least one currently-distributed
IPSEC implementation does just this, with the aim of p erforming \opp ortunistic
encryption" whenever possible.
Unfortunately, proto cols that merely arrange for packets to b e protected un-
der security associations do nothing to address the problem of enforcing a
policy
regarding the ow of incoming or outgoing trac. Recall that p olicy control is
a central motivation for the use of network-layer security proto cols in the rst
place.
In general, and rather surprisingly, security association policy is largely an
open problem { one with very important practical security implications and
with the potential to provide a solid framework for analysis of network security
properties.
Fortunately, the problem of policy management for security associations can
be distinguished in several imp ortantways from the problem of ltering individ-
ual packets. In particular:
{
SAs tend to b e rather long-lived; there is \lo cality of reference" insofar as
hosts that have exchanged one packet are very likely to also exchange others
in the near future.
{
It is acceptable for SA creation to require substantially more resources than
can be expended on processing every packet (
e.g.,
public key operations,
several packet exchanges, p olicy evaluation,
etc.
)
{
The \output" of negotiating an SA b etween two hosts can provide (among
other things) parameters for lower-level packet ltering operations.
A trust-management system[BFL96], such as
KeyNote
[BFK99], may be of
value here.

4 A Trust Management Architecture for Network Layer
Security
The problem of controlling SAs in a network-layer security proto col is easy to
formulate as a trust-management problem. Trust-management systems are char-
acterized by:
{
A metho d for describing \actions," which are op erations with security con-
sequences that are to b e controlled by the system.
{
A mechanism for identifying \principals," which are entities that can be
authorized to perform actions.
{
A language for sp ecifying application \policies," which govern the actions
that principals are authorized to p erform.
{
A language for specifying \credentials," which allow principals to delegate
authorization to other principals
{
A \compliance checker," which provides a service for determining how an
action requested by principals should b e handled, given a p olicy and a set
of credentials.
The trust-management approach has a number of advantages over other
mechanisms for specifying and controlling authorization, esp ecially when secu-
rity p olicy is distributed over a network or is otherwise decentralized.
In the case of SA p olicy, the \actions" would represent the low-level packet
ltering rules required to allowtwo hosts to conform one another's higher-level
policies.
This suggests a simple framework for trust management for Network- Layer
Security:
{
Each host has its own trust-management-controlled policy governing SA cre-
ation. This policy species the classes of packets and under what circum-
stances the host will initiate SA creation with other hosts, and also what
types of SAs it is willing to allow other hosts to establish.
{
When two hosts discover that they require an SA, they each prop ose to one
another the \least p owerful" packet-ltering rules that would enable them to
accomplish their communication ob jective. Each host sends proposed packet
lter rules, along with credentials (certicates) that support the proposal.
The trust structure of these credentials is entirely implementation depen-
dent, and might include the arbitrary web-of-trust, globally trusted third-
parties, or anything in between.
{
Each host queries its trust-management system to determine whether the
proposed packet lters comply with local policy and, if they do, creates the
SA containing the sp ecied lters.
Other SA prop erties might also be sub ject to trust management policy.For
example, the SA p olicy might specify acceptable cryptographic algorithms and
key sizes, the lifetime of the SA, logging and accounting requirements,
etc.
).

Our architecture divides the problem of policy managementinto two natural
components: packet ltering, based on simple rules applied to every packet,
and trust management, based on negotiating and deciding which such rules are
trustworthy enough to install.
This distinction makes it possible to p erform the p er-packet policy opera-
tions at high data rates while eectively establishing more sophisticated trust-
management-based p olicy controls over the trac passing through a secure end-
point. Having such controls in place makes it easier to specify security policy for
a large network, and makes it especially natural to integrate automated policy
distribution mechanisms.
An important practical problem in introducing security p olicy mechanisms
is the transition from older schemes into the new one. Existing IPSEC security
policies, which are based only on packet lters, quite easily t into the trust
management framework. As the trust management mechanism is introduced,
lter-based p olicies can be mechanically translated into trust-management p oli-
cies and credentials.
5 Conclusions and Status
We have develop ed a number of trust management systems, and have started
examining the use of
KeyNote
in the engineering of network-layer security pro-
tocols. We are in the process of implementing an IPSEC architecture similar to
that describ ed ab ove; it is our hop e that the formal nature of trust management
will make possible network security congurations with provable properties. One
of the most relevant features of trust management to SA management is the han-
dling of policy delegation.
Furthermore, because KeyNote is application-indep endent, it can be used
to \tie together" dierent aspects of network security,beyond just IPSEC and
packet ltering. For example, a more comprehensive network security p olicy
could specify what mechanisms are acceptable for remote access to a private cor-
porate network over the Internet; such a policy might, for example, allow the use
of cleartext passwords only if trac is protected with IPSEC or some transport-
layer security proto col (
e.g.,
SSH [YKS
+
99]). Multi-layer policies would, of
course, require emb edding p olicy controls into either an intermediate security
enforcement no de (such as a rewall) or into the end applications.
Finally, if trust-management p olicies and credentials are built into the net-
work security infrastructure it maybepossible to use them as an \intermedi-
ate language" between the low-level application p olicy languages (
e.g.,
packet-
ltering rules) and higher-level policy sp ecication languages and to ols. A trans-
lation to ol would then be used to convert the high-level specication to the
trust-management system's language (and perhaps vice-versa as well). Such a
tool could make use of formal methods to verify or enforce that the generated
policy has certain properties.
There are many open, and we b elieve, quite interesting and important prob-
lems here.

Frequently asked questions

Q1. What contributions have the authors mentioned in the paper "Trust management and network layer security protocols" ?

In this paper, the authors examine the problem of managing policy in network-layer security protocols, and propose a trust-management architecture for network layer security that may satisfy both the expressibility and the performance issues. 

Q2. What is the standard protocol technique used in IPSEC?

The standard protocol technique, employed in IPSEC [KA98], involves \\encapsulating" an encrypted network-layer packet inside a standard network packet, making the encryption transparent to intermediate nodes that must process packet headers for routing, etc. 

Q3. What is the way to use a key-agreement protocol?

Two hosts can use any key-agreement protocol to negotiate keys with one another, and simply use those keys as part of the encapsulating and decapsulating packet transforms. 

Q4. What is the common way to handle packets?

It may be forwarded to some network interface, dropped, or queued until an SA is made available, possibly after triggering some automated key management mechanism such as the IPSEC ISAKMP protocol[HC98]. 

Q5. What is the problem of network-layer security?

the design of encapsulation techniques for basic authentication and con dentiality services is not a conceptually di cult problem, and networklayer security protocols, such as IPSEC, have matured to the point of being standardized and implemented by commercial vendors. 

Q6. How can lter-based policies be translated into trust management policies and credentials?

As the trust management mechanism is introduced, lter-based policies can be mechanically translated into trust-management policies and credentials. 

Q7. What is the common approach to a packet-level security problem?

The obvious approach involves the use of a public-key or Needham-Schroeder [NS78] based key distribution scheme as the basis for a protocol that creates a new SA with whatever host attempts to communicate unsecured tra c in a manner that fails the packet-level security policy.