Markku Korhonen
Tik- 110.551 Internetworking Seminar
Department of Computer Science
Helsinki University of Technology
markorho@snakemail.hut.fi
A Security Association (SA) is specified [6] to be a relationship or a contract between two or more communicating entities that describes how they will utilize security services to communicate securely. This shareable contract information must be agreed upon all the entities. When accessing SA attributes, entities use an identifier refered to as the Security Parameter Index (SPI) that belongs to the key-exchange procedure. When the packets are sent to a receiver the SPI is chosen by the receiver. Each station must remember the SPI used by its partners to identify the security context.
Two basic IPv6 security mechanisms are the Authentication Header (AH) [6] and the Encapsulating Security Payload (ESP) [7], which in some cases might be combined to obtain the desired security properties.
The IPv6 Authentication Header (AH) provides integrity and authentication for IPv6 datagrams by computing a cryptographic authentication function over the IPv6 datagram and using a secret authentication key in this computation [6]. The sender computes the authentication data for static fields just prior to sending the authenticated IPv6 packet and the receiver verifies the correctness of the authentication data upon reception. Non-repudiation might be provided by some (e.g. asymmetric) authentication algorithms used with the Authentication Header. The default authentication algorithm is keyed MD5 [24], which like all symmetric algorithms cannot provide non-repudiation. Confidentiality and traffic analysis protection are not provided by the AH.
The IPv6 Encapsulating Security Payload (ESP) provides integrity, authentication, and confidentiality for IPv6 datagrams by encapsulating either an entire IPv6 datagram or only the upper-layer protocol data inside the ESP, encrypting most of the ESP contents, and finally a new cleartext IPv6 header is appended to the ESP [7]. The recipient of the datagram removes and discards the cleartext IPv6 header and options, decrypts the ESP, processes and removes the ESP headers, and then processes the data as normally.
A more descriptive information about AH and ESP can be found e.g., in [1].
The key management protocol is coupled to the other security mechanisms only via the SA. IPv6 is not intended to support so-called "in-band" key management, where the key management data is carried in a distinct IPv6 header. Instead it will primarily use the so-called "out-of-band" key management, where the key management data will be carried by an upper layer protocol such as UDP or TCP. This permits clear decoupling of the key management mechanism from the other security mechanisms, so it is possible to replace key management method with another one and without having to modify the implementations of the other security mechanisms [8].
In [25] key management concerns issues like Generating keys, Transferring keys, Verifying keys, Using keys, Updating keys, Storing keys, Back-up keys, Lifetime of keys, Destroying keys, etc. In this presentation our focus is more limited and not all the topics mentioned above are covered here. Our main interest is focused on key exchange protocols. It has been shown, in [13], that key exchange must be coupled to authentication.
In [20], the properties of key exchange protocols are defined to include the key establishment method, authentication, symmetry, perfect forward secrecy, and back traffic protection. The meaning of those terms is presented below in according to reference mentioned above.
In Key Establishment, the two common methods of using public key cryptography are key transport and key generation. An example of key transport is the use of the RSA algorithm [25], to encrypt a randomly generated session key with the other party's public key. The encrypted random key is then sent to the recipient, who decrypts it using his private key. At this point, both sides have the same session key. An example of key generation is the use of the Diffie-Hellman Algorithm (DH) [25], that generates a session key based on public and secret information held by both users. The DH algorithm is begun by two parties exchanging public information. Each party then mathematically combines the other's public information along with their own secret information to compute a shared secret value. This secret value can be used as a session key or as a key for encrypting a randomly generated session key.
Key exchange authentication may be done during the protocol or after protocol completion. Authentication of the key exchange during the protocol is provided when each party provides proof it has the secret session key before the end of the protocol. Proof can be provided by encrypting known data in the secret session key during the protocol exchange. Authentication after the protocol must occur in following communications. Authentication during the protocol is preferred so subsequent communications are not initiated if the secret session key is not established with the desired party.
A desirable key exchange symmetry is achieved if either party can initiate the exchange and exchanged messages can cross in transit without effecting the key that is generated.
Perfect Forward Secrecy is provided by a key exchange protocol if disclosure of long-term cryptographic keying material (e.g. public signature keys) does not compromise previously generated keys. Past session keys will not be obtainable if the long-term key is compromised in perfect forward secrecy.
Back Traffic Protection is provided by the independent generation of each key in a such way that subsequent keys are not dependent on any previous key. Past session keys will not be obtainable if the current session key is compromised in back traffic protecion.
What follows is a brief discussion of a few alternative forms for key management. However, multicast Key Distribution is not covered here.
There are a number of key management algorithms that have been described in the public literature. Needham and Schroeder have proposed a key management algorithm which is based on a centralised key distribution system [21, 22]. This algorithm is used in the Kerberos Authentication System [18]. Diffie and Hellman algorithm on the other hand does not require a centralised key distribution system [12, 19].
Use of IPv6 security will require an Internet-standard scalable key management protocol. There is work in progress to add signed host keys to the Domain Name System [14]. The DNS keys enable the originating party to authenticate key management messages with the other key management party using an asymmetric algorithm. The two parties could then create a shared session key using DH or other means.
There are two keying approaches for IPv6. In the host-to-host keying approach, all users of a host share the same key to be used with all users on another communicating host. In the user-to-user keying approach, every user has a unique session key.
2.3 IPv6 Key Management Requirements
In [8] IPv6 Key Management Requiremets are
specified as follows:
"All IPv6 implementations must support manual key management and should support an Internet standard key management protocol once it is approved. All IPv6 implementations must permit the configuration and use of user-to-user keying for traffic originating at that system and may additionally permit the configuration of host-to-host keying for traffic originating at that system as an added feature to make manual key distribution easier and give the system administrator more flexibility" [8].
"A device that encrypts or authenticates IPv6 packets originated on other systems, for example a dedicated IP encryptor or an encrypting gateway, cannot generally provide user-to-user keying for traffic originating on other systems. Hence, such systems must implement support for host-to-host keying for traffic originating on other systems and may implement support for user-to-user keying for traffic originating on other systems. The method by which keys are configured on a particular system is implementation-defined" [8].
In the rest of this paper, some proposed Ipv6 key management protocols are briefly introduced. These are Photuris, SKIP, ISAKMP, DNS security extensions and SKEME but because of the limited scope of this seminar some protocols e.g. Oakley [23] are excluded here.
Photuris is a session-key management protocol intended to be used with the IPv6 AH and ESP Security Protocols. In Photuris, a wide variety of session-key generation techniques are supported and it is independent of any particular party identification method or certificate format.
The following description of Photuris is mainly based on Christian Huitema's clear presentation in [15]. However, for the sake of clarity explicit references are not commonly indicated in the text.
The Photuris is based on the zero-knowledge key exchange algorithm of Diffie and Hellman (DH). In the original DH proposal parties A and B both know a prime number p and a generator g. The party A then chooses a random number x as an exponent and computes the value n = g^x mod p that is transferred to B. B, respectively, chooses a random number y, computes the value m = g^y mod p and transfers the value to A. At this stage A knows m and x, B knows n and y while third parties may know m or n, but cannot obtain either of exponents x or y. A and B can then compute the session key as follows: z = n^y mod p = m^x mod p = g^xy mod p. This shared secret key could the be used by the encryption or the authentication algorithm. The DH exchange can be implemented with other mathematical techniques, such as elliptic curve groups [17].
3.3 Photuris Exchanges
The Photuris protocol (see figure 1) starts by a cookie exchange,
followed by a DH exchange that will either prevent the clogging
attack or lead the intruder to disclose its IP-address. Finally
the signature message exchange take place.
Initiator Responder
------------------------------------------------------------
cookie-request--------------------------------------->
<--------------------------------------------cookie-response
key-request----------------------------------------->
<--------------------------------------------key-response
computation computation
Signature-------------------------------------------->
<--------------------------------------------Signature
Figure 1. The Photuris exchange
3.3.1 Cookie exchange
The cookie request contains a 128-bit initiator chosen cookie, that is a
random number used as an exchange identifier. The cookie request also contains
a list of groups to designate how the DH exchange has implemented.
The current draft [17] supplies three groups,
identified by their 8-bit numbers.
When a responder receives a cookie request, it examines the list of groups provided by the requestor and chooses an appropriate one. The responder will then in turn compute a responder cookie, e.g. by applying a MD5 to a string composed of the source address and UDP port of the message, the initiator cookie, and a secret number drawn by the responder when it was initialized.
The cookie response contains a selected group index, a copy of the initiator cookie, a responder cookie, a responder public value, and a list of attributes. The responder cookie identifies the exchange for the responder. The format of responder public value depends on the selected group. The list of attributes contains a set of transforms, in order of responder preference. Attributes are identified by an 8-bit type number.
Initiators associate a timer with each exchange. If the response does not arrive within a certain time, the procedure will be retried with a different initiator cookie. The cookie value is changed because the responder may keep copies of the recently received requests and refuse to serve them more than once. Saturated receivers may also ignore incoming cookie requests, if too many SA's are active at the same time.
Once the initiator has received the cookie response, it chooses a half-key and the corresponding public value in the indexed group, the number space chosen by the responder. It also chooses the attributes that will be used in the SA in the initiator-to-responder direction and sends a key request message.
The session keys can be computed immediately after the exchange of half-keys. The session key will be formally composed of the DH shared secret, concatenated with the SPI, the SPI owner cookie and the peer cookie. The actual key will then be shortened by applying a one-way function such as MD5 to this string to obtain a set of 128 bits used in the SA. The particular hash function that will be used is chosen from the initiator's list of attributes and indicated in the key transform parameter. A different key will be used in each direction.
The short lifetime of the SA (e.g. 30 seconds) is chosen by the responder. Long lifetimes increase the risk of compromising the key. It is preferable to reinitiate the SA and to compute new keys.
3.3.3 Signature exchange
The signature exchange is needed because neither cookie exchange nor the DH
exchange cannot prove the identity of the parties. The signature request
message sent by the initiator contains the initiator and receiver cookies,
an electronic signature, the certificates used for that signature and some
additional attributes. The signature transforms will typically consist of a
one-way function followed by an RSA exponentiation with the private key of
initiator. The particular one-way function, public key exponentiation method,
and the public key certification method are chosen from the responder's
list of attributes.
The transform is applied to a string made of the session key, concatenated with the initiator's public value, the responder's public value, and optionally the identifiying public key, certificate, or distinguishing name of the sender. Inclusion of the public values in the string guarantees that a man in the middle has not substituted its own value. If the verification succeeds, the responder computes its own signature and sends it to the initiator. It it fails, an error message is sent and the SA is not established.
3.4 Attacks that the Photuris guards against
The original DH algorithm has certain known weaknesses
[15]: It does not provide any information about
the identities of the parties, it is subject to the man-in-the-middle
attack and the involved heavy computational load can be used in a
clogging attack.
Using zero-knowledge exchanges the keys are computed when needed and the exchange does not require any preexisting infrastructure such as key servers or certificate servers.
Photuris supports a variety of authentication methods that can be coupled with the key exchange [17]. Adequate authentication will prevent the man-in-the-middle attack. Photuris uses a set of predefined primes that avoids the long computation required to discover long prime numbers and also enables stations to choose random half-keys and to compute the corresponding exponentation in advance.
4. Simple Key-Management for Internet Protocols (SKIP)
In order to implement SKIP, each IP based source and destination shall have a DH [12] public value. This value can be authenticated by use of X.509 certificates [5], Secure DNS [14] or PGP certificates [9] etc.
An IP source I has a secret value i, and a public value g^i mod p and a destination node J has values j and g^j mod p respectively. A mutually authenticated shared secret is defined as g^ij mod p.
The key g^ij mod p is called the long-term secret, and from it a key Kij can be derived by taking the low order key-size bits of g^ij mod p. Kij is used as the key for a block Symmetric Key CryptoSystem (SKCS) like DES, RC2 or IDEA.
A Kij is an implicit pairwise shared key that does not need to be sent in any packet or negotiated out-of-band. The destination node can compute this shared key (Kij) simply by knowing the source node's authenticated public value.
By using Kij a transient packet key Kp is encrypted. This packet key is used when IP packet encryption / authentication take place. Because Kij is valid for a relatively long period of time, the IP data traffic is not encrypted using key Kij. Kij is called a master key because it encrypts only other keys.
In order to prepare a packet for transmission to recipient J there is no need for communication with node J. When the recipient J receives this packet, it also computes the shared secret Kij and saves it to be used later. By using Kij it obtains Kp, and by using Kp it obtains the original IP packet.
If the source node I changes the Kp, the receiving IP node J can discover this fact without having to perform a computationally expensive public key operation. It uses the previously saved value Kij to decrypt the encrypted packet key Kp. Thus, without requiring communication between ends, the packet encrypting / authenticating keys can be changed by the transmitting side and discovered by the receiving side.
Because of the master keys Kij and traffic encryption keys Kp are separated, it is possible for the SKIP to automatically update Kp's even when manual master key distribution is utilized.
In [3] Kij must be 256 bits long and if Kij is derived from g^ij mod p, then the low order 256 bits are used as the input to the Kijn calculation. Master key computation is presented in fully detail in [3].
Although the descriptions above have utilized classic DH, the protocols can be applied to any public key agreement system, that is defined as a system where one combines another's public and one's own private value to compute a pairwise shared secret.
If the packet authentication keys Kp are ever compromised, then the master key update algorithm described in [3] precludes the re-use of compromised keys. This is because even if a particular traffic key Kp is compromised, the current implicit key Kijn is not compromised, and therefore the attacker would not be able to compute the encryption of Kp in Kijn. "Without knowing the encryption of Kp under the Kijn, an attacker cannot re-use past compromised keys Kp to any advantage" [3].
Also, even if all the keys Kp encrypted in a given Kijn are compromised, an attacker cannot learn anything about other Kp or to learn Kijn. "Knowing or even choosing Kp keys, and using that to learn Kijn is equivalent to a known or chosen plain-text attack on a Kijn, and that should be infeasible even given a very large number of known / chosen Kp keys as long as the key-encryption algorithm is practically secure against a known / chosen text attack" [3]. If the key-encryption algorithm is secure against a known / chosen text attack then is also SKIP secure.
In order to prevent resource clogging attacks, a recommended solution is to pre-compute and cache master keys Kij, based either on usage patterns of the machine or through administrative action mentioned in [3].
5. Internet Security Association and Key Management Protocol
5.1 Introduction to ISAKMP
"Internet Security Association and Key Management Protocol (ISAKMP)
combines the security concepts of authentication, key management,
and SAs to establish the required security for government, commercial,
and private communications on the Internet" [20].
The ISAKMP defines procedures and packet formats to establish and negotiate SA's and to modify or delete them. These packet formats provide a consistent method of exchanging key generation and authentication data that is independent of the key generation technique, encryption algorithm or authentication mechanism.
The description of ISAKMP below is based on draft [20] even though it might not be explicitly mentioned in the text.
For authentication ISAKMP utilizes digital signatures, based on public cryptography, but there is no specific signature algorithm or certificate authority (CA) that must be used. There are other strong authentication systems available (e.g. [18]), which could be specified.
An agreeded basic set of security attributes is established in an initial protocol exchange between source and destination node and this set provides protection for subsequent ISAKMP exchanges. This set also indicates the authentication and key exchange method that will be used in the ISAKMP protocol. After this initial identity authentication and required key generation, another security attribute exchange takes place to establish the complete SA which will be used for subsequent communications by the entity that invoked ISAKMP. In the ISAKMP protocol users can choose key establishment algorithms according their requirements.
+-------------+ +------------------+
! Negotiation ! Situation ! Application !
! Server !<------- ! Process !
+-------------+ ! +------------------+
! ISAKMP ! ! ! Appl Protocol !
+-------------+ ! +------------------+
! v !
+------------------------------------------------------+
! Sockets !
+------------------------------------------------------+
! Transport Protocol (TCP / UDP) !
+------------------------------------------------------+
! IP !
+------------------------------------------------------+
! Link Layer Protocol !
+------------------------------------------------------+
"The negotiation server is an application process which interfaces with the different policy databases (security, network access, cryptographic, authentication, etc.) that a system may require" [20]. Negotiation Server calls ISAKMP to deliver the data required to establish an SA and key and authenticate the exchange. The negotiation server itself can be invoked manually by a user or automatically by a security protocol when an SA is required.
The situation contains the identification and other information required by the negotiation server to make policy decisions. Upon completion of SA negotiation the SPI is returned.
As an example the Base Exchange is shown in figure 3. The Identity Protection Exchange and the Authentication Only Exchange can be found with full details in [20].
SA Initialization, Key Exchange and Authentication, and SA Negotiation comprise the base exchange. The base exchange contains the minimum number of packet exchanges in order to reduce SA establishment overhead.
_______Initiator_______Direction______Responder_______ Note_______________
ISA_INIT_REQ =>
<= ISA_INIT_RESP
Basic SA selected
ISA_AUTH&KE_REQ =>
<= ISA_AUTH&KE_RESP
Identity Verified
Key Generated
Encryption Begun
ISA_NEG_REQ =>
<= ISA_NEG_RESP SA Completed
Figure 3. Base Exchange
5.4 Attacks that the ISAKMP guards against
As noted by Karn [17], absolute protection against denial
of service is impossible, but the use of cookie exchange provides
a technique for making it easier to handle.
ISAKMP prevents connection hijacking by linking the authentication, key exchange and security association exchanges [20]. This linking also prevents man-in-the-middle types of attacks from being successful, because partial SA's will not be created.
6. Domain Name System (DNS) Security Extensions
The extensions also provide for the storage of authenticated public keys that can support general public key distribution service as well as DNS security. By using these public keys, security aware resolvers can learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be made to support other protocols and key types.
This short introduction is fully based on a draft [14], even though not always explicitly expressed so below.
6.2 Overview of the Extensions
The DNS protocol security extensions provide three distinct services:
key distribution, data origin authentication, and transaction
and request authentication, which all are briefly presented.
For a resolver to reliably learn the public key by reading it from DNS, the key itself must be signed. To provide a reasonable degree of security, the resolver must be staticly configured with at least the public key of one zone, where it can securely read the public keys of other secure zones.
6.2.3 DNS Transaction and Request Authentication
In order to provide protection for DNS requests or for message headers,
transaction authentication can be added. "This authentication means that
a resolver can be sure it is at least getting messages from the server it
thinks it queried, that the response is from the query it sent,
and that these messages have not been diddled in transit
[14].
The KEY RR is used to document a public key that is associated with a DNS name. This can be the public key of a zone, a host or other end entity, or a user. A KEY RR is authenticated by a SIG RR.
The SIG RR authenticates other RRs of a particular type, class, and name and binds them to a time interval and the signer's domain name. This is done using cryptographic techniques with the signer's private key. The signer is frequently the owner of the zone from which the RR originated.
The zone private keys should be kept and used in off-lineand in non-network connected physically secure machines only. The master copy of the zone file should be off net and should not be updated based on an unsecured network communication. Secure resolvers need to be configured with some trusted on-line public key information.
7. SKEME: A Versatile Secure Key Exchange Mechanism for Internet
SHARE EXCH AUTH ------------------------------------------------------------------------------- A -> B: PKEB (KA) A -> B: gx mod p A -> B: FK0 (gy,gx, idA, idB) B -> A: PKEA (KB) B -> A: gy mod p B -> A: FK0 (gx,gy, idB, idA) K0 = H (KA, KB)The EXCH -phase is used to exchange DH exponents. The authentication of this DH exchange is complished in a AUTH phase, which uses the shared key K0 from SHARE to autenticate DH exponents. The combination of the EXCH and AUTH phases provides the protocol with the strong perfect forward secrecy (PFS). FK0 represents a pseudorandom function using key K0 and that provides the functionality of a message authentication.
For the sake of communications efficiency, the above phases can be combined unto three messages as described below:
A
PKEB ( idA , KA ), gx
---------------------------------------------->B
K0 = H (KA,KB )
PKEA ( KB ), gy , FK0 (gx, gy, idB, idA)
<------------------------------------------------
K0 = H (KA, KB )
FK0 (gy, gx, idA, idB)
------------------------------------------------->
SK := H (gxy mod p )
Some variations of this basic protocol can be found in
[19].