Furthermore, the number of key exchanges to be triggered depends
on security policy issues like lifetime of a security
association, required security properties of the key exchange
protocol, authentication mode used by the key exchange protocol,
etc. In a stationary environment with a single administrative
domain, manual security association establishment may be
acceptable and may provide the best performance characteristics.
In a mobile environment, asymmetric authentication methods are
likely to be used with a key exchange protocol, and some sort of
public key or certificate verification needs to be supported.
4.3. User to PEP/PDP
As noted in the previous section, RSVP supports both user-based and
host-based authentication. Using RSVP, a user may authenticate to
the first hop router or to the PDP as specified in [1], depending on
the infrastructure provided by the network domain or the architecture
used (e.g., the integration of RSVP and Kerberos V5 into the Windows
2000 Operating System [25]). Another architecture in which RSVP is
tightly integrated is the one specified by the PacketCable
organization. The interested reader is referred to [26] for a
discussion of their security architecture.
(1) Authentication
When a user sends an RSVP PATH or RESV message, this message may
include some information to authenticate the user. [7] describes
how user and application information is embedded into the RSVP
message (AUTH_DATA object) and how to protect it. A router
receiving such a message can use this information to authenticate
the client and forward the user or application information to the
policy decision point (PDP). Optionally, the PDP itself can
authenticate the user, which is described in the next section.
To be able to authenticate the user, to verify the integrity, and
to check for replays, the entire POLICY_DATA element has to be
forwarded from the router to the PDP (e.g., by including the
element into a COPS message). It is assumed, although not
clearly specified in [7], that the INTEGRITY object within the
POLICY_DATA element is sent to the PDP along with all other
attributes.
* Certificate Verification
Using the policy element as described in [7], it is not
possible to provide a certificate revocation list or other
information to prove the validity of the certificate inside
the policy element. A specific mechanism for certificate
verification is not discussed in [7] and hence a number of
them can be used for this purpose. For certificate
verification, the network element (a router or the policy
decision point) that has to authenticate the user could
frequently download certificate revocation lists or use a
protocol like the Online Certificate Status Protocol (OCSP)
[27] and the Simple Certificate Validation Protocol (SCVP)
[28] to determine the current status of a digital certificate.
* User Authentication to the PDP
This alternative authentication procedure uses the PDP to
authenticate the user instead of the first-hop router. In
Section 4.2.1 of [7], the choice is given for the user to
obtain a session ticket either for the next hop router or for
the PDP. As noted in the same section, the identity of the
PDP or the next hop router is statically configured or
dynamically retrieved. Subsequently, user authentication to
the PDP is considered.
* Kerberos-based Authentication to the PDP
If Kerberos is used to authenticate the user, then a session
ticket for the PDP must be requested first. A user who roams
between different routers in the same administrative domain
does not need to request a new service ticket, because the
same PDP is likely to be used by most or all first-hop routers
within the same administrative domain. This is different from
the case in which a session ticket for a router has to be
obtained and authentication to a router is required. The
router therefore plays a passive role of simply forwarding the
request to the PDP and executing the policy decision returned
by the PDP. Appendix B describes one example of user-to-PDP
authentication.
User authentication with the policy element provides only
unilateral authentication, whereby the client authenticates to
the router or to the PDP. If an RSVP message is sent to the
user’s host and public-key-based authentication is not used,
then the message does not contain a certificate and digital
signature. Hence, no mutual authentication can be assumed.
In case of Kerberos, mutual authentication may be accomplished
if the PDP or the router transmits a policy element with an
INTEGRITY object computed with the session key retrieved from
the Kerberos ticket, or if the Kerberos ticket included in the
policy element is also used for the RSVP INTEGRITY object as
described in Section 4.2. This procedure only works if a
previous message was transmitted from the end host to the
network and such key is already established. Reference [7]
does not discuss this issue, and therefore there is no
particular requirement for transmitting network-specific
credentials back to the end-user’s host.
(2) Integrity Protection
Integrity protection is applied separately to the RSVP message
and the POLICY_DATA element, as shown in Figure 1. In case of
a policy-ignorant node along the path, the RSVP INTEGRITY
object and the INTEGRITY object inside the policy element
terminate at different nodes. Basically, the same is true for
the user credentials if they are verified at the policy
decision point instead of the first hop router.
* Kerberos
If Kerberos is used to authenticate the user to the first hop
router, then the session key included in the Kerberos ticket
may be used to compute the INTEGRITY object of the policy
element. It is the keyed message digest that provides the
authentication. The existence of the Kerberos service ticket
inside the AUTH_DATA object does not provide authentication or
a guarantee of freshness for the receiving host.
Authentication and guarantee of freshness are provided by the
keyed hash value of the INTEGRITY object inside the
POLICY_DATA element. This shows that the user actively
participated in the Kerberos protocol and was able to obtain
the session key to compute the keyed message digest. The
Authenticator used in the Kerberos V5 protocol provides
similar functionality, but replay protection is based on
timestamps (or on a sequence number if the optional seq-number
field inside the Authenticator is used for KRB_PRIV/KRB_SAFE
messages as described in Section 5.3.2 of [8]).
* Digital Signature
If public-key-based authentication is provided, then user
authentication is accomplished with a digital signature. As
explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE
attribute must be the last attribute in the AUTH_DATA object,
and the digital signature covers the entire AUTH_DATA object.
In the case of PGP, which hash algorithm and public key
algorithm are used for the digital signature computation is
described in [19]. In the case of X.509 credentials, the
situation is more complex because different mechanisms like
CMS [29] or PKCS#7 [30] may be used for digitally signing the
message element. X.509 only provides the standard for the
certificate layout, which seems to provide insufficient
information for this purpose. Therefore, X.509 certificates
are supported, for example, by CMS or PKCS#7. [7], however,
does not make any statements about the usage of CMS or PKCS#7.
Currently, there is no support for CMS or for PKCS#7 [7],
which provides more than just public-key-based authentication
(e.g., CRL distribution, key transport, key agreement, etc.).
Furthermore, the use of PGP in RSVP is vaguely defined,
because there are different versions of PGP (including OpenPGP
[19]), and no indication is given as to which should be used.
Supporting public-key-based mechanisms in RSVP might increase
the risks of denial-of-service attacks. The large processing,
memory, and bandwidth requirements should also be considered.
Fragmentation might also be an issue here.
If the INTEGRITY object is not included in the POLICY_DATA
element or not sent to the PDP, then we have to make the
following observations:
For the digital signature case, only the replay protection
provided by the digital signature algorithm can be used.
It is not clear, however, whether this usage was
anticipated or not. Hence, we might assume that replay
protection is based on the availability of the RSVP
INTEGRITY object used with a security association that is
established by other means.
Including only the Kerberos session ticket is insufficient,
because freshness is not provided (because the Kerberos
Authenticator is missing). Obviously there is no guarantee
that the user actually followed the Kerberos protocol and
was able to decrypt the received TGS_REP (or, in rare
cases, the AS_REP if a session ticket is requested with the
initial AS_REQ).
(3) Replay Protection
Figure 5 shows the interfaces relevant for replay protection of
signaling messages in a more complicated architecture. In this
case, the client uses the policy data element with PEP2, because
PEP1 is not policy-aware. The interfaces between the client and
PEP1 and between PEP1 and PEP2 are protected with the RSVP
INTEGRITY object. The link between the PEP2 and the PDP is
protected, for example, by using the COPS built-in INTEGRITY
object. The dotted line between the Client and the PDP indicates
the protection provided by the AUTH_DATA element, which has no
RSVP INTEGRITY object included.
AUTH_DATA +----+
+---------------------------------------------------+PDP +-+
| +----+ |
| |
| |
| COPS |
| INTEGRITY|
| |
| |
| |
+--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
|Client+-------------------+PEP1+----------------------+PEP2+-+
+--+---+ +----+ +-+--+
| |
+-----------------------------------------------------+
POLICY_DATA INTEGRITY
Figure 5: Replay Protection.
Host authentication with the RSVP INTEGRITY object and user
authentication with the INTEGRITY object inside the POLICY_DATA
element both use the same anti-replay mechanism. The length of
the Sequence Number field, sequence number rollover, and the
Integrity Handshake have already been explained in Section 3.1.
Section 9 of [7] states: "RSVP INTEGRITY object is used to
protect the policy object containing user identity information
from security (replay) attacks." When using public-key-based
authentication, RSVP-based replay protection is not supported,
because the digital signature does not cover the POLICY_DATA
INTEGRITY object with its Sequence Number field. The digital
signature covers only the entire AUTH_DATA object.
The use of public key cryptography within the AUTH_DATA object
complicates replay protection. Digital signature computation
with PGP is described in [31] and in [19]. The data structure
preceding the signed message digest includes information about
the message digest algorithm used and a 32-bit timestamp of when
the signature was created ("Signature creation time"). The
timestamp is included in the computation of the message digest.
The IETF standardized version of OpenPGP [19] contains more
information and describes the different hash algorithms (MD2,
MD5, SHA-1, RIPEMD-160) supported. [7] does not make any
statements as to whether the "Signature creation time" field is
used for replay protection. Using timestamps for replay
protection requires different synchronization mechanisms in the
case of clock-skew. Traditionally, these cases assume "loosely
synchronized" clocks but also require specifying a replay window.
If the "Signature creation time" is not used for replay
protection, then a malicious, policy-ignorant node can use this
weakness to replace the AUTH_DATA object without destroying the
digital signature. If this was not simply an oversight, it is
therefore assumed that replay protection of the user credentials
was not considered an important security requirement, because the
hop-by-hop processing of the RSVP message protects the message
against modification by an adversary between two communicating
nodes.
The lifetime of the Kerberos ticket is based on the fields
starttime and endtime of the EncTicketPart structure in the
ticket, as described in Section 5.3.1 of [8]. Because the ticket
is created by the KDC located at the network of the verifying
entity, it is not difficult to have the clocks roughly
synchronized for the purpose of lifetime verification.
Additional information about clock-synchronization and Kerberos
can be found in [32].
If the lifetime of the Kerberos ticket expires, then a new ticket
must be requested and used. Rekeying is implemented with this
procedure.
(4) (User Identity) Confidentiality
This section discusses privacy protection of identity information
transmitted inside the policy element. User identity
confidentiality is of particular interest because there is no
built-in RSVP mechanism for encrypting the POLICY_DATA object or
the AUTH_DATA elements. Encryption of one of the attributes
inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is
discussed.
To protect the user’s privacy, it is important not to reveal the
user’s identity to an adversary located between the user’s host
and the first-hop router (e.g., on a wireless link).
Furthermore, user identities should not be transmitted outside
the domain of the visited network provider. That is, the user
identity information inside the policy data element should be
removed or modified by the PDP to prevent revealing its contents
to other (unauthorized) entities along the signaling path. It is
not possible (with the offered mechanisms) to hide the user’s
identity in such a way that it is not visible to the first
policy-aware RSVP node (or to the attached network in general).
The ASCII or Unicode distinguished name of the user or
application inside the POLICY_LOCATOR attribute of the AUTH_DATA
element may be encrypted as specified in Section 3.3.1 of [7].
The user (or application) identity is then encrypted with either
the Kerberos session key or with the private key in case of
public-key-based authentication. When the private key is used,
we usually speak of a digital signature that can be verified by
everyone possessing the public key. Because the certificate with
the public key is included in the message itself, decryption is
no obstacle. Furthermore, the included certificate together with
the additional (unencrypted) information in the RSVP message
provides enough identity information for an eavesdropper. Hence,
the possibility of encrypting the policy locator in case of
public-key-based authentication is problematic. To encrypt the
identities using asymmetric cryptography, the user’s host must be
able somehow to retrieve the public key of the entity verifying
the policy element (i.e., the first policy-aware router or the
PDP). Then, this public key could be used to encrypt a symmetric
key, which in turn encrypts the user’s identity and certificate,
as is done, e.g., by PGP. Currently, no such mechanism is
defined in [7].
The algorithm used to encrypt the POLICY_LOCATOR with the
Kerberos session key is assumed to be the same as the one used
for encrypting the service ticket. The information about the
algorithm used is available in the etype field of the
EncryptedData ASN.1 encoded message part. Section 6.3 of [8]
lists the supported algorithms. [33] defines newer encryption
algorithms (Rijndael, Serpent, and Twofish).
Evaluating user identity confidentiality also requires looking at
protocols executed outside of RSVP (for example, the Kerberos
protocol). The ticket included in the CREDENTIAL attribute may
provide user identity protection by not including the optional
cname attribute inside the unencrypted part of the Ticket.
Because the Authenticator is not transmitted with the RSVP
message, the cname and the crealm of the unencrypted part of the
Authenticator are not revealed. In order for the user to request
the Kerberos session ticket for inclusion in the CREDENTIAL
attribute, the Kerberos protocol exchange must be executed. Then
the Authenticator sent with the TGS_REQ reveals the identity of
the user. The AS_REQ must also include the user’s identity to
allow the Kerberos Authentication Server to respond with an
AS_REP message that is encrypted with the user’s secret key.
Using Kerberos, it is therefore only possible to hide the content
of the encrypted policy locator, which is only useful if this
value differs from the Kerberos principal name. Hence, using
Kerberos it is not "entirely" possible to provide user identity
confidentiality.
It is important to note that information stored in the policy
element may be changed by a policy-aware router or by the policy
decision point. Which parts are changed depends upon whether
multicast or unicast is used, how the policy server reacts, where
the user is authenticated, whether the user needs to be re-
authenticated in other network nodes, etc. Hence, user-specific
and application-specific information can leak after the messages
leave the first hop within the network where the user’s host is
attached. As mentioned at the beginning of this section, this
information leakage is assumed to be intentional.
(5) Authorization
In addition to the description of the authorization steps of the
Host-to-Router interface, user-based authorization is performed
with the policy element providing user credentials. The
inclusion of user and application specific information enables
policy-based admission control with special user policies that
are likely to be stored at a dedicated server. Hence, a Policy
Decision Point can query, for example, an LDAP server for a
service level agreement that states the amount of resources a
certain user is allowed to request. In addition to the user
identity information, group membership and other non-security-
related information may contribute to the evaluation of the final
policy decision. If the user is not registered to the currently
attached domain, then there is the question of how much
information the home domain of the user is willing to exchange.