Subject: RE: [NSIS] Key management

From: [email-masked]
Date: Tue, 12 Nov 2002 12:51:53 +0200

Hi all,

Just as an FYI, I pinged the Security ADs about attending the Wednesday
meeting, so hopefully they can help us out on this discussion.

thanks,
John
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 12 Nov 2002 14:57:08 +0100

hi all

i tried to compile some security issues which arise when looking at
signaling protocols (with RSVP as an example). it would be nice to receive
your comments, corrections and thoughts.

Three security related signaling protocol issues
------------------------------------------------

1. First-Peer Issues

In case of end-to-end signaling an end host starts signaling to its attached
network. The first-peer communication is often more difficult because of the
different requirements and a missing trust relationship. An end host must
therefore obtain some information to start RSVP signaling:

- Does this network support RSVP signaling?
- Which node supports RSVP signaling?
- To which node is authentication required?
- Which identity is used for authentication?
- Which security mechanisms are used for authentication?
- Which algorithms have to be used?
- Where should the keys/security association come from?
- Should a security association be established?

RSVP, as specified today, is used as a building block. Hence these questions
have to be answered as part of overall architectural considerations. Without
giving an answer to this question "ad-hoc" RSVP communication by an end host
roaming to an unknown network is not possible. A negotiation of security
mechanisms and algorithms is not supported for RSVP.

2. Next-Peer Issues

It is often assumed that the next RSVP node along the path is always known.
Knowing your next peer is important to be able to select the key for the
RSVP Integrity object to provide proper protection. In case that an RSVP
node assumes to know which node is the next peer then the following protocol
exchange can occur:

                                 Integrity
                                  (A<->C)    +------+
                                   (3)       | RSVP |
                              +------------->+ Node |
                              |              |  B   |
                 Integrity    |              +--+---+
                  (A<->C)     |                 |
       +------+    (2)     +--+---+             |
  (1)  | RSVP +----------->+      |             |  Error
 ----->| Node |            |Router+<------------+ (I am B)
       |  A   +<-----------+      |       (4)
       +------+    (5)     +--+---+
                  Error       .
                 (I am B)     .              +------+
                              .              | RSVP |
                              ...............+ Node |
                                             |  C   |
                                             +------+
            Figure 1: Next-Peer Problem

When RSVP node A in Figure 1 receives an incoming RSVP Path message then
standard RSVP message processing takes place. Node A then has to decide
which key to select to protect the signaling message. We assume that some
mechanism which is not further specified is used to make this decision. In
this example node A
assumes that the message will travel to RSVP node C. However because of some
reasons (e.g. a route change, inability to learn the next RSVP peer along
the path, etc.) the message travels to node B via a non-RSVP supporting
router which cannot verify the integrity of the message (or cannot decrypt
the Kerberos service ticket). The processing failure causes a PathErr
message to be returned to the originating sender of the Path message. This
error message also contains information about the node recognizing the
error. In many cases a security association might not be available. Node A
receiving the PathErr message might use the information returned with the
PathErr message to select a different security association (or to establish
one). The RSVP Path message therefore provides a number of functions: path
discovery, detecting route changes, learning of QoS capabilities along the
path using the Adspec object, (with some interpretation) next-peer discovery
and possibly security association establishment (for example in case of
Kerberos).

From a security point of view there is a conflict between

- Idempotent messages delivery and efficiency

Especially the RSVP Path message performs a number of functions. Supporting
idempotent message delivery somehow contradicts with security association
establishment and efficient message delivery and size. For example a "real"
idempotent signaling message would contain enough information to perform
security processing without depending on a previously executed message
exchange. Adding a Kerberos ticket with every signaling message is, however,
very inefficient. Using public key based mechanisms is even more inefficient
when included in every message. With public key based protection for
idempotent messages there is additionally a risk of introducing denial of
service attacks.

- RSVP Path message functionality and next-peer discovery

To protect an RSVP signaling message (and a RSVP Path message in particular)
it is necessary to know the identity of the next RSVP aware node (and some
other parameters). Without a mechanism for next-peer discovery an RSVP Path
message is also responsible for this task. Without knowing the identity of
the next peer the Kerberos principal name is also unknown. The so-called
Kerberos user-to-user authentication mechanism is not supported which would
allow the receiver to trigger the process of establishing Kerberos
authentication is not supported. This issue will again be discussed in
relationship with the last-peer problem.

It is fair to assume that a RSVP supporting node might not have a security
association with all possible RSVP nodes in the neighborhood. Especially for
inter-domain signaling or IntServ over DiffServ the number of next-peer RSVP
nodes might be considerably large. Hence a node transmitting a RSVP Path
message might experience difficulties to properly protect the message if it
serves as a means to detect route changes at the same time. It is fair
noting that in a intra-domain case this might be possible due to manual
configuration in case of a dense distribution of RSVP nodes.

Denial of Service Problem

An adversary could continuously flooding a node with bogus PathErr messages.
A legitimate RSVP node would believe that a change in the path took place.
Hence this node would try to select a different security association or try
to create one with the indicated node. Hence an adversary can send a PathErr
message at any time to confuse an RSVP node. If an adversary is located
along somewhere along the path then it might also be possible to
act as a man-in-the-middle adversary if either authentication and/or
authorization is not performed with the necessary accuracy.

3. Last-Peer Issues

This section tries to address practical difficulties when authentication and
key establishment is accomplished with a protocol which shows some asymmetry
in message processing when executed between two nodes. Kerberos is such a
protocol and also the only supported protocol which provides dynamic session
key establishment for RSVP. For first-peer communication authentication is
typically done between a user and some network in the network (for example
the access router). Especially in a mobile environment it is not feasable to
authenticate end hosts based on their IP or MAC address. To show the problem
the typical processing steps for Kerberos are shown for first-peer
communication:

a) The end host A learns the identity (i.e. Kerberos principal name) of some
entity B. This entity B is either the next RSVP node or a PDPor the next
policy aware RSVP node.

b) Entity A then requests a ticket granting ticket for the network domain.
This assumes that the identity of the network domain is known.

c) Entity A then requests a service ticket for entity B which was learned in
step (a).

d) Entity A includes the service ticket to the RSVP signaling message
(inside the policy object). The Kerberos session key is used to protect the
entire RSVP signaling message.

For last-peer communication this processing step theoretically has to be
reversed; entity A is then a node in the network (for example the access
router) and entity B is the other end host. This assumes that RSVP signaling
is accomplished between two end hosts and not between an end host and a
application server. The access router might however in step (a) not be able
to learn the identity of the user's principal name since this information
might not be available. Entity A could reverse the process by triggering an
IAKERB exchange. This would cause entity B to request a service ticket for A
as described above. IAKERB is, however, not supported.

---------------------------------

ciao
hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 12 Nov 2002 14:57:15 +0100

hi all

based on our recent discussion about ipsec protection of rsvp signaling
message i tried to write a more detailed text explaining the different
issues. i would be nice to receive some feedback:

IPsec protection of RSVP signaling messages
-------------------------------------------

It was often mentioned that RSVP signaling messages can be protected by
IPsec in a hop-by-hop fashion between two adjacent RSVP nodes. Some RSVP
signaling message require, however, special processing which complicates
IPsec protection. This section tries to describe these complications.

RSVP messages are transmitted as raw IP datagrams with protocol number 46.
It might be possible to encapsulate them in UDP as described in Appendix C
of RFC 2205. Some RSVP messages (Path, PathTear, and ResvConf) must have the
Router Alert IP Option set in the IP header. These messages are addressed to
the (unicast or multicast) destination address and not to the next RSVP node
along the path. Hence an IPsec traffic selector can only use these fields
for IPsec SA selection. If there is only a single path (and possibly every
traffic is protected) then there is no problem for IPsec protection of
signaling messages. This type of protection is not common and might only be
used to secure network access between an end host and its first-hop router.
Since the described RSVP messages are addressed to the destination address
instead of the next RSVP node it is not possible to use IPsec in transport
mode - only IPsec in tunnel mode is possible.

If there is more than one possible path which an RSVP message can take then
the IPsec engine will experience difficulties to protect the message. Even
if the RSVP daemon installs a traffic selector with the destination ip
address then still there is no distinguishing element which allows to select
the correct security association of one of the possible RSVP nodes along.
Even if it possible to apply IPsec protection (in tunnel mode) for RSVP
signaling messages by incorporating some additional information then there
is still the possibility that the tunneled messages do not recognize a path
change in a non-RSVP router. Then the signaling messages would simply follow
different path than the data.

RSVP messages like Resv can be protected by IPsec since they are contain
enough information to create IPsec traffic selectors which allow a
differentiation between different next RSVP nodes. A traffic selector would
then contain the protocol number and the source / destination address pair.

ciao
hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 12 Nov 2002 14:57:16 +0100

hi all

at the last ietf meeting i was asked about the implications of ipsec
protected data traffic for rsvp. please send me your comments.

Implications of IPsec protected data traffic
--------------------------------------------

QoS signaling requires flow information to be established at routers along a
path. This flow identifier installed at each devices tells the router which
data packets should experience QoS treatment. RSVP typically establishes a
flow identifier based on the 5-tuple (source IP address, destination IP
address, tranport protocol type, source port and destination port). If this
5-tuple information is not available then other identifiers have to be used.
IPsec protected data traffic is such an example where the transport protocol
and the port numbers are not accessible. Hence the IPsec SPI is used as a
substitute for them. RFC 2207 considers these IPsec implications for RSVP
and is based on three assumptions:

a) An end host, which initiates the RSVP signaling message exchange, has to
be able to retrieve the SPI for given flow. This requires some interaction
with the IPsec SADB and SPD. An application usually does not know the SPI of
the protected flow and cannot provide the desired values. It can provide the
signaling protocol daemon with flow identifiers. The signaling daemon would
then need to query the IPsec security association database by providing the
flow identifiers as input parameters and the SPI as an output parameter.

b) RFC 2207 assumes an end-to-end IPsec protection of the data traffic. In
IPsec is applied in a nested fashion then parts of the path do not
experience QoS treatment. This problem can be treated as a tunneling problem
but is initiated by the end host. A figure better illustrates the problem in
case of enforcing secure network access:

+------+          +---------------+      +--------+          +------+
| Host |          | Security      |      | Router |          | Host |
|  A   |          | Gateway (SGW) |      |   Rx   |          |  B   |
+--+---+          +-------+-------+      +----+---+          +--+---+
   |                      |                   |                 |
   |IPSec-Data(           |                   |                 |
   | OuterSrc=A,          |                   |                 |
   | OuterDst=SGW,        |                   |                 |
   | SPI=SPI1,            |                   |                 |
   | InnerSrc=A,          |                   |                 |
   | OuterDst=B,          |                   |                 |
   | Protocol=X,          |IPSec-Data(        |                 |
   | SrcPort=Y,           | SrcIP=A,          |                 |
   | DstPort=Z)           | DstIP=B,          |                 |
   |=====================>| Protocol=X,       |IPSec-Data(      |
   |                      | SrcPort=Y,        | SrcIP=A,        |
   | --IPsec protected->  | DstPort=Z)        | DstIP=B,        |
   |    data traffic      |------------------>| Protocol=X,     |
   |                      |                   | SrcPort=Y,      |
   |                      |                   | DstPort=Z)      |
   |                      |                   |---------------->|
   |                      |                   |                 |
   |                      |     --Unprotected data traffic->    |
   |                      |                   |                 |
            Figure 1: Next-Peer Problem

Host A transmitting data traffic would either indicate a 3-tuple
<A,SGW,SPI1> or a 5-tuple <A,B,X,Y,Z>. In any case it is not possible to
make a QoS reservation for the entire path. Similar examples are remote
access using a VPN, protection of data traffic between the home agent (or a
security gateway in the home network) and the mobile node and other. With a
nested application of IPsec (for example IPsec between A and SGW and between
A and B) the same problem occurs.

One possible solution to this problem is to change the flow identifier along
the path to capture the new flow identifier after an IPsec endpoint.

IPsec tunnels which neither start nor terminate at one of the signaling end
points (for example between two networks) should be addressed differently by
recursively applying an RSVP signaling exchange for the IPsec tunnel. RSVP
signaling within tunnels is addressed in RFC 2746.

c) It is assumed that SPIs do not change during the lifetime of the
established QoS reservation. If a new IPsec SA is created then a new SPI is
allocated for the security association. To reflect this change either a new
reservation has to be established or the flow identifier of the existing
reservation has to be updated. Since IPsec SAs have a longer lifetime this
issue does not seem to be a major issue. IPsec protection of SCTP data
traffic might more often require an IPsec SA (and an SPI) change to reflect
added and removed IP addresses from an SCTP association.

ciao
hannes