Chapter 13: IPv6 Key Management Issues and Protocols

Introduction

The Internet is an open system, where the identity of the communicating partners is not easy to define. In addition, the communication path is non-physical and can include any number of eavesdropping possibilities.

From a users or organizations point of view, secure communications are frequently a necessary part of Internet communications. Cryptography (to assure privacy and security) and certification (to assure that communication is happening between the desired parties) are considered necessary Internet features. They must be used together. Key management is an integral part of secure communications.

This chapter briefly:

• Describes the possible placement of IP security mechanism in the TCP/IP stack and some of the key management design objectives of the IP security protocols.
• Provides a refresher of the IPv6 key management requirements
• Lists some questions to ask yourself to help you decide which key management system to implement
• Introduces some certification and key distribution methods, identifies some key management issues, and lists some IPv6 key management requirements
• Describes some issues revolving around security implementations for IPv6 and introduces some key management and key exchange protocols including:
  
  The Simple Key-Management for Internet Protocols (SKIP) specification; a session-less key management protocol designed to work with the IP Security Protocols AH and ESP
  
  The Internet Security Association and Key Management Protocol (ISAKMP) that defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation
  
  The Oakley and ISAKMP/Oakley protocols that provides several options for key exchange, perfect forward secrecy features, and methods to provide for long-term security
• Introduces the Secure Key Exchange Mechanism for Internet (SKEME) as an example of a key exchange protocol
• Provides some information about Domain Name System Protocol Security Extensions and its use in key management and exchange

The authentication of principals to one another is at the heart of any key exchange scheme. Authenticating principals over the Internet is no exception and the Internet community must decide on a scaleable standard for solving this problem.

All network security such as encryption of data for privacy and packet and user authentication require key management. A key is a unique piece of data used along with an encryption algorithm (a series of math steps) to create the resulting secure information. Key management is the process of creating and assigning keys to users and security products and periodically changing the keys.

Any key-management system that can scale to the number of nodes possible in the Internet must be based on an underlying authenticated public-key-based infrastructure. The work is ongoing in the IETF to specify key management protocols and to provide technical support for the public key infrastructure.

From the users point of view, the IPv6 security mechanism including key management protocols will have a lot of flexibility and alternatives to choose from. Users are not tied to any specific implementation but they can change an applied method implementation when their needs change or for other reasons.

Implementing IPsec in the TCP/IP stack

IPsec refers to the security mechanisms, and protocols, including key management protocols, that make up the various components of the IP security architecture. You can logically define IPsec as part of the upper half of the TPC/IP model IP layer as shown in .

There are a number of ways you might implement IPsec as part of the logical IP layer including

1. Implementing IPsec above the IP layer. In this case you can only have a transport mode ESP. You need an implementation of the TCP/IP logical interface and the IP layer source code to be available.
2. Implementing IPsec inside the IP layer. In this implementation, you need the IP layer source code to be available.
3. Implementing IPsec below the IP layer. This choice is independent of the particular TCP/IP stack implementation.

Independent key management mechanism

The IP security architecture separates the key management mechanisms and the security mechanism. The IPsec security mechanism are flexible and users have alternatives to choose from. These mechanisms are not tied to any specific cryptographic algorithms, so they can be altered without affecting the other parts of the implementation. The key management protocol that an IPv6 implementation uses is coupled to the other security mechanisms only through the security association. A well defined security association interface to an organization’s IP security implementation makes it possible to:

• Replace the key management part with new key management protocols when a better one becomes available
• Change the existing key management protocol to a better one as their needs change

Independence of the cryptographic algorithms

The IPsec deliberately separates the IP security mechanisms AH and ESP (see Chapter 12) from the cryptographic algorithms and transformations. A well-defined protocol-algorithm interface to your implementation if IPv6 security makes it possible to easily add new algorithms and transformations as they are developed. You can also replace an encryption algorithm with a stronger one if you find security Holes in the existing algorithm. And you can change the algorithms without changing the whole AH and ESP implementations.

Security of the keys in the host

The IPsec requires the key management portion to pay special attention to the security of the keys in the IP host system. For example, you could place the keys on separate hardware outside the host operating system . In this case the key parameters for the operating system level security associations use a key index to refer to the specific key.

Refresher of IPv6 key management requirements

The Security Architecture for the Internet Protocol, RFC 1825 defines the key management requirements for all IPv6 implementations and for those IPv4 implementations that implement the IP Authentication Header, the IP Encapsulating Security Payload, or both. RFC 1825 states that the method by which keys are configured on a particular system is implementation-defined.

The following list highlights the major requirements.

• All such implementation must support manual configuration of security associations. A flat file containing security association identifiers and parameters, including the keys, is an example of one possible method for manual key distribution.
• All Implementations should support Internet standard key management protocol once one is published as an Internet standards-track RFC.
• All such implementations should support an Internet standard Security Association establishment one is published as an Internet standards-track RFC. Implementation can also support other methods of configuring security associations.
• It must be possible to have more than one concurrent security association between two endpoints.
• Implementations on multi-user hosts should support user-oriented security associations. All such implementations must permit the configuration of host-oriented keying.
• An IP host must take reasonable steps to protect the keys and other security association information from unauthorized examination or modification.

Questions to ask when selecting a key management system

Because a transition to a public key management standard will be required, it is essential that your system provide a graceful upgrade process. Selecting a key management system that can be easily upgraded to meet evolving public key standards is quite a challenge. Indeed, it might require some extensive research on your part. If key management is weak or unproved, the strength of the encryption does not matter. Answers to the following questions can help you decide which system to implement:

• What type of security mechanism does the currently available key management use?
• How secure is the currently available key management?
• Does the vendor have an established record in Public Key Technology?
• Does the vendor have a good record when it comes to complying with standards?
• Does the vendor provide reliable support
• Is upgrading easy and does the vendor have a upgrade support policy?
• Can you upgrade the firmware?
• Can you upgrade the software?
• Does the system support backward compatibility with previously deployed products?

Basic key management

Key management is the process of assigning keys to users and security products and periodically changing the keys. Generally a key management systems should provide for:

• Controlled management of keys to provide for adherence to security policy.
• Frequent and automatic key changes to provide high level of security and discourage hackers
• Long key length to provide protection against hackers attempting to break the key

Type of key management

There are two of key management: secret key management that is also known as symmetrical key management, and public key management that is also known as asymmetrical key management.

Secret key management involves using shared keys between two users, devices, or locations that need to communicate. In a secret key system, the key used in combination with an algorithm such as DES encrypts data. The recipient uses the same key and algorithm to decrypt the data. Both ends of a connection share the same key.

Public key management involves using two keys. These keys are often referred to as a public key pair and consist of a:

• Public key that is available for everyone to use and used for encryption
• Private key that is known only to the user and used for decryption

A message encrypted with a user's public key can only be decrypted with the corresponding private key and visa versa. Public Key Management must involve a trusted third party known as a Certificate Authority (CA). The CA's main responsibility is to guarantee or certify that a particular public key belongs to a certain user.

The CA grants a public key certificate to a user meeting the requirements for the particular type of certificate. The certificate contains information about the user's identity and public key. The certificate is signed by the CA using a digital signature which is a cryptographic hash computed over the certificate data using the CA's private key. In effect, the CA electronically vouches for the binding of the certificate to a specific user or product.

Encryption and decryption of data using public key technology is rarely done because it is computationally slow. The most common uses of public key cryptography include:

• User authentication
• Digital signature creation
• Secure exchange of session keys

A system can uses the session key to encrypt the data. Systems can establish a session key in one of two ways: using public key encryption or using a distribution/exchange algorithm.

Method 1: A user can generate a random session key, encrypt the session key with the other user’s public key, and send the encrypted session key to the other user. The other user decrypts the session key using its private key and proceeds with secure communications.

Method 2: A user can use a key distribution/exchange algorithm such as Diffie-Hellman (DH) to generate a common shared secret key without ever exchanging the secret key.

A public key management system allows secure communication between users previously unknown to one another. It also provides for secure interoperability between products from different router, encryptor, firewall and software providers.

Certification methods

A key management scheme for the Internet must be based on a public key management standards. However, absolute certification methods are a logical impossibility because a certificate cannot certify itself. Three paradigms for dealing with the basic certification include:

• Directory methods such as those represented by X.509 certificates and Certification Authorities (CAs)
• Introducer or referral methods such as those represented by Pretty Good Privacy (PGP)
• Collaborative methods such as those represented by Simple Key-Management for Internet Protocols (SKIP)

Directory methods

The International Telecommunication Union (ITU) X.509 standard provides an example of the directory method for authenticating public keys using certificates. The ITU is the specialized agency of the United Nations for Telecommunications. This type of authentication is provided by public key certificates and CAs.

SSL is perhaps the widest used security protocol on the Internet today and implements X.509 certificates. These certificates are not human readable; the user has to take for granted that it is correct.

X.509, an international standard defines a framework for authentication services for its users under a central control mechanism represented by a Directory to its users. It describes two levels of authentication:

• Simple authentication that uses a password to verify the claimed identity of the participant or participants in the communication.
• Strong authentication that involves credentials formed using cryptographic techniques.

While simple authentication offers some limited protection against unauthorized access, you should use only strong authentication as the basis for providing secure services.

The X.509 recommendation depends on many other standards, amendments, internet drafts, and other work-in-progress documents. Therefore there can be a number of independent interpretations of X.509. This has also led to a number of poorly defined market names, such as Digital-ID and others, that hide the dependency on X.509 but which never the less depend on the same concepts.

The X.509 certificates need a Directory service that deals with the users. This means that X.509 needs Certification Authorities (CAs). A CA issues standard X.509 certificates. A CA essentially provides a secure binding between an entity's name (or identifier) and its public key. This is to assure third parties that some measure of care was taken to ensure that this binding is valid.

A CA is usually self-certified although some depend on other CAs that in turn are self-certified. You can use can use one or more CAs, depending on your location and ease of access to a CA. As a general rule, CA are independent; there could be many independent CAs in the same country.

The CA paradigm is essentially to rely on an authentication chain that ends in a CA that eventually certifies itself.

Introducer or referral methods

The referral method of certification depends on the integrity of a chain of authenticators, the users themselves. The Pretty Good Privacy (PGP) secure e-mail software package is a example of this type of authentication. This type of authentication is sometimes referred to as the Introducer method.

The users and their keys are referred from one user to the other and thus forming an authentication chain or a web-of-trust. If you are a participant in this type of authentication chain, you might not know the last person who entered the chain or if everyone on your chain has a valid entry. Each user maintains the chain by changing, adding, or deleting data. There is no guarantee that the chain is up-to-date. With this referral method there is no entity responsible if something goes wrong, not even the user.

Better tools than those currently available would be needed for central administration of PGP trust parameters in a corporate system. Note that central administration is a way to guarantee accountability, coherence, dependability, and correct authentication.

PGP has the benefit of being able to interoperate with a trusted CA . The CA, as a trusted Introducer, guarantees certificates. And PGP is flexibility which makes it a good example of a quasi-decentralized system.

Collaborative methods

SKIP is an example of the collaborative method of certification. SKIP operates at the IP layer and implements a linked chain of two-sided node authenticators. Each node authenticator gets its information from a type of directory service. SKIP uses authenticated Diffie-Hellman (DH) public values to acquire and change packet encrypting keys. This avoid the need for pseudo-session state management between the two ends. Authenticated DH public values serve as the basis for a very simple, efficient, and stateless key-management scheme.

E. Gerck says in Overview of Certification Systems: X.509, CA, PGP and SKIP that because non-repudiation and other security features that depend on certificates also depend on data from the application layer the SKIP protocol needs to be complemented by a second authentication protocol, in a higher layer.

SKIP lacks user-tunable controls; such as the rejection or choice of certificates. The SKIP design removes control decisions from the user; for example, the user can not decide which node authenticator is reliable.

Key management issues

A key-management scheme that can scale to the number of nodes possible in the Internet needs to be based on an underlying public key infrastructure. Authentication of these public keys could occur through a variety of methods such as public key certificates, a secure directory server, or a web-of -trust implementation. Secure Domain Name Security (DNS) provides an example of authenticating public keys (and other resources) using a secure directory service.

TIP: In most existing applications the key being authenticated is assumed to be a key for a public key cryptosystem such as RSA.

RSA is a public key cryptographic algorithm named for its inventors (Rivest, Shamir, and Adleman) that does encryption and digital signatures.

Several key management and distribution systems will be usable with the IP Security (IPsec) specifications. The IPsec protocol provides a standard way that businesses can an encrypted link to a trading partner's network. The Encryption of the link occurs after authentication which occurs at an IPsec-based firewall or gateway. Generally an X.509 digital certificate is used for authentication.

The current key distribution and management and distribution options required for both AH and ESP for IPv4 and IPv6 are manual keying and automated keying through ISAKMP + Oakley and SKIP.

The actual method to be employed for IPv6 implementations is unresolved. At this point, ISAKMP is required for IPv6 with SKIP as an option. IP secure implementations of IPv4 can use either ISAKMP or SKIP. At a minimum AH requires HMAC with MD5 or SHA-1 and ESP requires DES CBC.

SKIP is a sessionless and stateless protocol for exchanging keys and uses in-band key management techniques. ISAKMP depends on two-way statefull communications and uses out-or-band key management techniques.

The key management protocol is coupled to the other security mechanisms only through the SA. There are two ways authenticated RSA public keys can provide authenticity and privacy for a datagram protocol. Key management could be either in-band key management, or out-of-band key management.

Work is still ongoing within the IETF to fully specify an Internet Standard key management protocol.

Out-of band key management

Some argue that IPv6 in intended to support only out-of-band key management as defined in the proposed Internet Security Association and Key Management Protocol (ISAKMP),. In out-of-band key management, an upper layer protocol such as UDP or TCP carries the key management data. These protocols might carry key management data on a specific port or distribute the key management data manually. This makes it possible to replace or update a key management method with another one. You can update key management without having to modify the implementations of the other security mechanisms and without seriously effecting your implementation of the security protocol. Out-of-band key management is statefull and session based.

Prior to a communication, Ian out-of-band implementation uses one of several session key creation protocols and out-of-band techniques to create an authenticated session key. The implementation then uses this session key to encrypt or authenticate IP data traffic.

In an out-of-band key management scheme, the IP source:

• Needs to establish and securely manage a pseudo-session layer underneath IP.
• Needs to communication with the IP destination to acquire the session key

The IP protocol does not require intermediate nodes to maintain any kind of state on a per-communications-instance basis. Each IP packet is independently routable. Secure management of the pseudo-session state can involve establishing mechanism for:

• Secure crash recovery
• Rerouting and load balancing of IP traffic.

Without knowledge of the transient session key with which the packets are protected, another intermediate node is not able to decrypt or authenticate rerouted IP traffic.

In-band key management

Some argue that IPv6 can support both out-of-band and in-band key management. In an in-band implementation a distinct IPv6 header carries the key management data. A stateless key-management design could use authenticated RSA public keys.

This might work through in-band signaling of the packet encryption key, where the packet encryption key is encrypted in the recipient's RSA public key. This arrangement does not need an out-of-band communication session to change. Packet encryption keys. However, this arrangement means that each IP packet has to carry the packet encryption key encrypted in the recipient’s public key.

Alternatively, acquiring and changing packet encrypting keys could be done using authenticated Diffie-Hellman public values. Authenticated DH public values serve as the basis for a very simple, efficient, and stateless key-management scheme. As described in the SKIP specification, this stateless key-management scheme permits dynamic rerouting of protected IP traffic through alternate encrypting intermediate nodes for crash-recovery, fail-over, and load-balancing scenarios.

Key transport and generation

describes what happens when you use key transport and key generation which are two common methods of using public key.

The benefit of the DH algorithm is that the key used for encrypting messages is based on information held by both users and the independence of keys from one key exchange to another provides perfect forward secrecy.

Key distribution methods

The simplest form of key management is manual key management. There are a number of key management algorithms that have been described in the public literature. Much work is going into defining IPv6 Internet-standard scaleable key management protocol.

There are two keying approaches for IPv6: the host-to-host keying approach and user-to-user keying approach

Manual key distribution

In a manual key management system a person manually configures each system with it own key and with the keys of other communicating systems. Manual key distribution is impractical in medium to large scale environments. However, manual key distribution might be a viable choice in a small LAN. There are a number of instances when manually configuring keys could be appropriate. For example, a system administrator of a small LAN could configure keys:

• When only selected communications need to be secured
• When each router needs to protect routing data and reduce the risk of an intruder breaking into a router.
• When the organization has several remote sites connected through the Internet but each site has an encrypting firewall between its internal network and the Internet. In this case the firewall might use a manually configured key to encrypt the traffic for other sites belonging to the organization. The firewall would not encrypt traffic for other destinations.

Automated key distribution

Widespread use of IP security will require an Internet key management protocol. that can support a number of protocols within the Internet protocol suite; not just the IP security protocols. There are a number of key management algorithms that have been described in the public literature. For example, the Domain Name System Security Extensions protocol (RFC 2065) supports signed host keys and provides three distinct services:

• Public key and signed host key storage and distribution services
• Data origin authentication services
• Transaction and request authentication services.

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.

Resource records associate keys with DNS names which permits DNS to be used as a public key distribution mechanism. The key resource record contains parameters for the public key, an algorithm identifier, and assorted flags. When a security aware DNS server receives a request for a resource record, it automatically returns the key resources along with the resource record.

The DNS keys let the originating party authenticate key management messages with the other party using an asymmetric algorithm. The resulting communications channel between the two parties could be authenticated and could be used to create a shared session key.

Donald Eastlake and Charles Kaufman state in RFC 2065 that "at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems."

Host- and user-oriented keying

IP security supports two types of keying; host-oriented and user-oriented keying. In host-oriented keying all the user on a particular host share the same key to apply to traffic going to all the users on host 2. If host-oriented keying is in use, all sending user IDs on a given system have the same security association for a given destination address.

You can have a situation where two users of a system that uses host-oriented keying do not trust each other. It is possible in this situation for one of the users to determine the host-oriented key and use it to either read or forge traffic for or from the other user. When you use user-oriented keying, such an attack from one user onto another users traffic is not possible.

User-oriented keying lets an individual user on host 1 have one or more unique session keys to use with traffic going to host 2. Other users on host 1 do not share these session keys.

If a system has multiple sensitivity levels, users would typically have a session key for each sensitivity level that they are authorized to use. For example, a user on host 1 might have a key for UNCLASSIFIED traffic, another for SECRET TRAFFIC and yet another for TOP SECRET traffic.

You can have a situation where two users of a system that uses host-oriented keying do not trust each other. It is possible in this situation for one of the users to determine the host-oriented key and use it to either read or forge traffic for or from the other user. When you use user-oriented keying, such an attack from one user onto another users traffic is not possible.

Multicast key distribution

A system administrator could use manual key distribution when a multicast group has just a few members. In such a situation the multiple use of existing unicast key distribution algorithms might also be possible. For very large groups, new scaleable techniques will be needed and are under active investigation

The key management protocols

The IPsec protocols for key management generally fall into one of two types, although some encompass both type of protocols. The two types of key management protocols are:

• Protocols that define the procedures and packet formats to establish, negotiate, modify, and delete Security Associations. Examples of this type of protocol include the Simple Key-Management for Internet Protocols (SKIP), and the Internet Security Association and Key Management Protocol (ISAKMP).
• SKIP describes a session-less key management protocol intended for use with IPsec protocols that provides privacy and authentication for communicating parties and runs over IP.
• ISAKMP provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independent; that is, it is designed to support many different key exchanges.
• Protocols that define key exchange mechanisms. Examples of this type of protocol include the OAKLEY Key Determination Protocol commonly referred to just as Oakley, The Resolution of ISAKMP with Oakley, and the Secure Key Exchange Mechanism for Internet (SKEME) specification.
• Oakley describes a series of key exchanges called modes and details the services provided by each, such as perfect forward secrecy for keys, identity protection, and authentication.
• Resolution of ISAKMP with Oakley describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI.
• SKEME describes a versatile key exchange technique which provides anonymity, repudability, and quick key refreshment.

The Domain Name System (DNS) Security Extensions protocol provides some features of both types of protocols.

Properties of key exchange protocols include the key establishment method, authentication, symmetry, perfect forward secrecy, and back traffic protection.

Simple key-management for internet protocols

The Simple Key-Management for Internet Protocols (SKIP) is a session-less key management protocol intended for use with the IP Security Protocols AH and ESP for both IPv4 and IPv6. SKIP provides privacy and authentication for communicating parties. The description of SKIP below is based on the SKIP specifications even though it might not be explicitly mentioned in the text.

The Diffie-Hellman key public value algorithm

Each IP-based source and destination in a SKIP implementation has an authenticated Diffie-Hellman public value. The authenticated Diffie-Hellman key agreement protocol allows two parties to authenticate themselves to each other using digital signatures and public key certificates. For example, the DH value could be authenticated using an X.509 certificates, Secure DNS, or even PGP certificates.

SKIP uses the authenticated Diffie-Hellman public values to avoid having to use a pseudo session state between the sender and recipient to acquire and change packet encrypting keys. Authenticated DH public values serve as simple, efficient, and stateless key-management scheme. Because of the use of DH values, SKIP permits dynamic rerouting of protected IP traffic through alternate encrypting intermediate nodes for crash-recovery, fail-over, and load-balancing scenarios.

The authenticated Diffie-Hellman key agreement protocol, or Station-to-Station (STS) protocol, was developed by Diffie, van Oorschot, and Wiener in 1992 to defeat the middle person attack for which the Diffie-Hellman key agreement protocol was vulnerable. The Diffie-Hellman key agreement protocol (also called exponential key agreement) was developed by Diffie and Hellman in 1976 and published in the ground-breaking paper New Directions in Cryptography. The protocol allows two users to exchange a secret key over an insecure medium without any prior secrets.

The SKIP keys

Each SKIP IP-based source and destination derives its shared secret master key from a combination of a secret value and the nodes authenticated public value. The master key encrypts only other keys. The master key is an implicit paired shared key that does not need to be sent in any packet and it does not need to be negotiated out-of-band. The destination node can compute this shared key simply by knowing the source node's authenticated public value. The master key is used as the key for a block Symmetric Key Cryptosystem (SKCS) like DES, RC2 or IDEA.

SKIP uses the master key to encrypt a transient packet key that is used for IP packet encryption and authentication. When the recipient receives the encrypted packet, it computes its the shared secret master key and uses that key to derive the transient packet key and uses that key to decrypt the packet.

The SKIP master key can be distributed manually if there is no automatic key distribution infrastructure in place. Because the master key and the traffic encryption keys (the transient packet keys) are separated, SKIP can automatically update the traffic encryption keys even manual master key distribution is in use.

SKIP assigned numbers

SHIP has a number of assigned values as shown in .

The Assigned Numbers for SKIP Protocols document, located at http://skip.incog.com/spec/numbers.html, lists all current number assignments. This document states "Numbers for all of the SKIP protocols may be requested by sending mail to numbers@skip.org. Please include references to transforms, algorithm, etc in your number assignment request. Assignments will only be made when information sufficient for independent implementation is provided."

Attack prevention

The use of Authenticated DH public values helps guard against man-in-the-middle attacks while the master key update algorithm precludes the reuse of compromised keys to send forged traffic.

Sometimes an attacker tries to effect a denial-of-service attach or clogging attack by trying to force the protocol to perform a lot of expensive computations like the DH computation. You can help prevent such denial-of-service attacks by precomputing and caching master keys based on usage patterns of the machine or through some sort of administrative action. If such an attack occurs, the IP node can still communicate with the machines for which it has precomputed master keys.

Store the keys belonging to administrators in the precompute cache. This allows the administrator to securely add more principals to the precompute cache, even during a clogging attack.

Internet Security Association and Key Management Protocol (ISAKMP)

The Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for Internet key management and provides protocol support for negotiation and management of security associations. Security associations contain all the information required for execution of various network security services. ISAKMP also defines the payloads for exchanging key generation and authentication data. It provides passive protection against for example, eavesdropping

The following description of ISAKMP is based on the ISAKMP draft document even though it is not explicitly mentioned in the text.

ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the network stack. By itself, ISAKMP does not establish session keys, however it can be used with various session key establishment protocols, such as Oakley, to provide a complete solution to Internet key management.

ISAKMP centralizes the management of security associations to reduce the amount of duplication within each security protocol. And ISAKMP can negotiate a whole stack of services at one time thus reducing connection setup time.

The major components of ISAKMP consists of security associations and management, authentication, public key cryptography, and protection mechanism. ISAKMP has basic requirements for its authentication and key exchange components. These requirements provide for threat mitigation and guard against denial of service, replay, man-in-the-middle, and connection hijacking attacks

ISAKMP authentication, key exchange, and protection

ISAKMP requires the use of a digital signatures such as the Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature along with certification from a trusted third party for authentication. The protocol does not require or specify a specific signature algorithm or certificate authority.

The CA defines the naming semantics for the certificates it issues. The protocol provides the messages required to support the actual authentication exchange. Based on user requirements, ISAKMP allows an entity initiating communications to indicate which key exchanges mechanism it uses. After selection of a key exchange, the protocol provides the messages required to support the actual key establishment. Protocol users can choose key establishment algorithms according their requirements.

In the ISAKMP a cookie or anti-clogging token helps protect the computing resources from attack. Absolute protection against denial of service is impossible, but this anti-clogging token provides a technique for making it easier to handle. The ISAKMP specification defines where abnormal processing has occurred and the linking of the ISAKMP exchanges prevents the insertion of messages in the protocol exchange and thus helps prevent Man-in-the-Middle attacks. ISAKMP also help prevent connection hijacking by linking the authentication, key exchange and security association exchanges

Concepts

shows a high level interpretation of the ISAKMP relationships within a network architecture. An important part of negotiating for security services is to think of all the security associations as protection suite. A protection suite is a list of the security services that each of the security protocols needs to apply. For example, a protection suite could consist of keyed MD5 authentication in IP AH and DES encryption in IP ESP.

The figure shows a representation of a DOI definition. A DOI is a Domain of Interpretation and defines the payload formats, exchange types, and conventions for naming security-relevant information. Security-relevant information can include such things as the security policies in use and the cryptographic algorithms in use. ISAKMP uses a DOI identifier to interpret the ISAKMP payloads. ISAKMP payloads provide modular building blocks for constructing ISAKMP messages.

A DOI defines the:

• Information that the protocol uses to determine the security services
• Security policies the communicating pair must support
• Syntax to use to specify proposed security services
• Scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, security policy attributes, and certificate authorities.

A ISAKMP negotiation session has two phases. In the first phase the negotiating pair agree how to protect further negotiations and establish an ISAKMP security association. ISAKMP uses the two cookie fields in the ISAKMP header to identify ISAKMP SAs. The security services that the communicating pair negotiate during the first phase provide the security properties for the second phase.

The second phase establishes the security associations for the other security protocols in use. The ISAKMP protocol uses the Message ID and SPI fields in the ISAKMP header during SA establishment to identify the SA for other security protocols. ISAKMP allows both initiator and responder to have some control during the negotiation process.

A security protocol can use the security associations from this second phase to protect numerous message/data exchanges. ISAKMP accomplishes the negotiation of each phase using ISAKMP-defined exchanges or exchanges defined for a key exchange within a DOI.

ISAKMP port assignment

A key management implementation can place ISAKMP over any transport protocol or over IP. IANA has assigned ISAKMP the User Datagram Protocol (UDP) port 500. All ISAKMP implements must include send and receive capability for ISAKMP over this port. Implementations can also support ISAMKL over other transport protocols.

The ISAKMP header

An ISAKMP message has a fixed header format followed by a variable number of payloads. The fixed header contains the necessary information to process payloads and possibly prevent denial of service or replay attacks. shows the ISAKMP header fields.

The ISAKMP header fields are defined as follows:

Initiator Cookie ¾ Cookie of the entity that in initiating the SA establishment, notification, or deletion

Responder Cookie ¾ Cookie of the entity that is responding to the SA establishment, notification, or deletion

Next Payload ¾ Indicates the value for the type of the first payload in the message as listed in .

Major Version ¾ Indicates the version of the ISAKMP protocol in use

Minor Version ¾ Indicates the minor version of the ISAKMP protocol in use

Exchange Type ¾ Indicates the value for the type of exchange in use. This value as shown in dictates the message and payload orderings in the ISAKMP exchanges.

Flags ¾ Indicates specific options that are set for the ISAKMP exchange as follows:

• E(ncryption Bit) ¾ If set (1), the protocol encrypts all payloads following the header using the encryption algorithm identified in the ISAKMP SA. The ISAKMP SA Identifier is the combination of the initiator and responder cookie.
• C(ommit Bit) ¾ The protocol uses this bit to signal key exchange synchronization. Key exchange synchronization ensures that encrypted material is not received before establishing the ISAKMP SA.

Message ID ¾ The Unique Message Identifier used to identify the protocol state during phase two negotiations. The initiator of phase two negotiations generates this random value. This value is set to 0 during phase one negotiations.

Length ¾ Indicates the length of total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message.

ISAKMP payload

The ISAKMP generic payload header shown in can chain multiple payloads and clearly defines the boundaries of a payload. The generic payload header fields are as follows:

Next Payload ¾ Contains the identifier for the payload type of the next payload in the message. This field provides the chaining capability.

RESERVED ¾ Unused,

Payload Length ¾ Indicates the length in octets of the current payload and includes the generic payload header itself.

There are quite a number of possible payloads. These include:

• Security Association Payload
• Proposal Payload
• Transform Payload
• Key Exchange Payload
• Identification Payload
• Certificate Payload
• Certificate Request Payload
• Hash Payload
• Signature Payload
• Nonce Payload
• Notification Payload
• Delete Payload

The OAKLEY Key Determination Protocol

The Oakley Key Determination Protocol is a key exchange protocol. The "Oakley" name is after the cowgirl Annie Oakley but the reason for this fun nomenclature is unknown to the writer. Oakley describes a series of key exchanges called modes and details the services provided by each such as perfect forward secrecy for keys, identity protection, and authentication.

The protocol, written by H. Orman, describes how two authenticated parties can agree on secure and secret keying material. This is accomplished using the Diffie-Hellman (DH) key exchange algorithm. The protocol is compatible with the ISASKMP protocol for managing security associations and supports Perfect Forward Secrecy. It also uses ISAKMP header and payload formats. Oakley supports user-defined abstract group structures for use with the Diffie-Hellman algorithm as well as key updates and incorporation of keys distributed through out-of-band mechanisms. The cryptographic techniques used in Oakley have survived substantial public scrutiny.

You can use Oakley by itself if no attribute negotiation is needed or you can use Oakley in conjunction with ISAKMP.

*** STAT NOTE ***

When you use Oakley with ISAKMP, key escrow is not feasible.

The description of Oakley below is based on draft even though it might not be explicitly mentioned in the text.

OAKLEY Key Determination Protocol overview

The establishment of keys is a major component of the packet protection mechanism described in the Security Architecture for the Internet Protocol (RFC 1825). Indeed, establishing keys is the heart of data protection that relies on cryptography. A scaleable and secure key distribution mechanism is needed for the Internet. The Oakley protocol with its DH key exchange algorithm provides that mechanism.

DH allows two parties to agree on a shared value without using encryption. This agreed upon shared value is immediately available to use to encrypt subsequent authentication and data transmissions. This means that the two parties can be sure of each other’s identities even when an active attacker exists.

Additionally, you can use Oakley to derive a new key from an existing key and to encrypt and distribute an externally derived key. You can use this generic key exchange protocol to generate keys with a long privacy lifetime of 20 years or more. The protocol provides several option to ensure the security of the keys; it includes:

• Cookies (anti-clogging tokens) to help avoid denial of service attacks

The cookies provide a form of source address identification for both parties. The cookie exchange can take place before each party performs and extensive computations such as large integer exponentiations. Actually, OAKLEY uses the cookies for two purposes: anti-clogging and key naming.

For example, at the beginning of key establishment, both parties contribute one cookie. The pair of cookies becomes the key identifier (KEYID) which is a reusable name for the keying material. The name of the key can be used later to derive the security associations for the AH (RFC1826) and ESP (RFC1827) protocols

• An option that allows two parties to select mutually agreeable supporting algorithms for the protocol

This second option includes choosing the encryption method, the key derivation method, and the authentication method.

• Derivation of keys for encryption that depends on DH and the cryptographic methods used by both parties to authenticate each other.

Each key is associated with algorithms that are used for authentication, privacy, and one-way functions. These are ancillary algorithms for OAKLEY

• Mechanisms for how the two parties can select the mathematical for performing the Diffie-Hellman algorithm by using standard groups or defining their own.
• The use of authentication based on symmetric encryption or non-encryption algorithms.

These features allow the communication parties to use the features that are best suited to their security and performance requirements.

Oakley and UDP

Oakley is a compatible component of ISAKMP that runs over UDP using the well-know port 500 (see the RFC on port assignments, STD02-RFC-1700).

NOTE: The assigned ports use a small portion of the possible port numbers. For many years the assigned ports were in the range 0-255. Recently, the range for assigned ports managed by the IANA has been expanded to the range 0-1023.

The protocol stack underlying Oakley must be able to supply the Internet address of the remote party for each message. You could use Oakley over IP or UDP if suitable protocol or port number assignments were available.

The key exchange message

Secure key exchange processing establishes common keying information for the communicating parties; including:

• A key name
• Secret keying material
• Identification of the two parties
• Three algorithms for use during authentication:
• An encryption algorithm for privacy of the identities of the two parties
• A hashing algorithm to protect the integrity of the messages and for authenticating message fields
• An authentication algorithm for the mutual authentication of the two parties

The communicating parties exchange messages specifying their requirements until they reach agreement on what constitutes the common keying information for their communication session.

The key exchange protocol

The message content of an Oakley key exchange depends on the options the initiator and responder want to use. A key exchange can be completed with three or more messages, depending on those options.

The three basic components of the key exchange protocol include:

• A cookie exchange
• A Diffie-Hellman half-key
• Authentication options for privacy

The method of authentication can be digital signatures, public key encryption, or an out-of-band symmetric key. The Initiator is responsible for retransmitting messages if the protocol does not terminate in a timely fashion.

Authentication

An Oakley implementation can incorporated a number of different authentication standards thereby providing a range of options to the communicating parties. These can include: pre-shared keys, DNS public keys, RSA public keys without a CA signature, RSA public keys with a CA signature, and DSS keys with certificates.

Generally Oakley validates authentication keys using a combination of the authentication algorithm, the identity of the authentication authority that must be apparent in the trust hierarchy, the authentication type such as PGP or RSA, and a key (usually public). The ISAKMP authentication payload defines the authentication authority field.

The ISAKMP Credentials Payload can be used to attach useful certificates to OAKLEY messages. Oakley implementations must provide support for accessing and revoking public key certificates through the Secure DNS protocol.

Some key use and distribution guidelines

If there is an existing authenticated key and its associated key material, Oakley could use a hashing function and derive additional keys that share similar attributes.

Oakley can use for any purpose a manually distributed key and its associated key identifier and state information

When you have an Oakley session key and its ancillary algorithms you can use them to distribute an externally generated key and to assign a key identifier (KEYID) to the key

When two parties do not have public keys that can authenticate each other, they can use manually distributed keys

The resolution of ISAKMP with Oakley

The ISAKMP and Oakley protocols have been combined into a hybrid protocol. The Resolution of ISAKMP with Oakley uses the framework of ISAKMP to support a subset of Oakley key exchange modes. This new key exchange protocol provides optional perfect forward secrecy, full security association attribute negotiation, as well as authentication methods that provide both repudiation and non-repudiation. You can use implementations of this protocol to establish Virtual Private Networks (VPNs) and also allow remote users who may have a dynamically allocated IP address access to a secure network. The protocol supports Proxy mode negotiation where the negotiating parties are not the end-points for whom the security association negotiation is taking place

This protocol uses part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP. You can also use this protocol and for other security associations such as AH and ESP for the IETF IPsec DOI. This protocol does not implement the entire SKEME protocol, but only the method of public key encryption for authentication and its concept of fast re-keying using an exchange of nonces.

Resolution of ISAKMP with Oakley Overview

Oakley uses modes and defines a way to establish an authenticated key exchange. ISAKMP defines phases. During ISAKMP’s phase one, the communication pair establishes a secure, authenticated channel for communication; also called the ISAKMP security association. The Oakley Main Mode, and Aggressive Mode accomplish a phase 1 exchange and occur only in phase 1.

• The phase 1 Main Mode provides identity protection
• The phase 1 Aggressive Mode is used when identity protection is not needed and reduces the number of round trips needed for the negotiation.

NOTE: Using public key encryption to authenticate an Aggressive Mode exchange still provides identity protection.

During ISAKMP’s phase two, the communicating pair negotiate security association for services such as AH and ESP when key material is needed. The Oakley Quick Mode accomplished a phase 2 exchange and occurs only in this phase. The Oakley New Group Mode also occurs only in phase 2.

• Quick Mode generates fresh keying material and negotiates non-ISAKMP security associations.
• New Group Mode establishes a new group that can be used in future negotiations.

The ISAKMP phases, make it possible for an implementation to accomplish very fast keying when necessary. A single phase 1 negotiation can be used for more than one phase 2 negotiation and a singe phase 2 negotiation can request many security associations.

Phase 1 negotiations establish the following ISAKMP SA attributes:

• The encryption algorithm to use such as DES or IDEA
• The hash algorithm to use such as MD5 or SHA
• The authentication method to use such as an RSA or DSS signature
• Information about a group over which to apply the Diffie-Hellman (DH) algorithm
• Information about the keyed hash function used to generate output to used for both key derivations and authentication such as 3DES-CBC-MAC.

At a minimum, ISAKMP/Oakley implementations support DES-CBC, MD5 and SHA, authentication through pre-shared key.

Mode exchanges

Both Main Mode and Aggressive Mode generate authenticated keying material from a DH exchange. This is done only for ISAKMP security associations. As stated previously, Quick Mode generates keying material for non-ISAKMP security associations. New group Mode defines private groups for Diffie-Hellman exchanges. All exchanges follow the ISAKMP payload syntax although Quick Mode and New Group Mode have no analog in ISAKMP.

The protocol permits three authentication methods with Main Mode and Aggressive Mode: digital signature, public key encryption, or pre-shared key. When using public keys for authentication, the Phase 1 exchange can be accomplished either by using signatures or by using public key encryption.

In order to perform the public key encryption, the initiator must already have the responder's public key. The ancillary information exchanged during public key authentication is encrypted nonces. If the authentication method is public key encryption, the identity payloads of the parties in addition to the nonce is encrypted with the other parties public key. The payload header is left in the clear.

In Main Mode the IP address of the peers identifies the key when using pre-shared key authentication. Aggressive Mode allows two parties to maintain multiple, different pre-shared keys.

Quick Mode in phase 2 is used as part of security association negotiation process for non-ISAKMP SAs. Quick Mode is essentially an exchange of nonces that provides replay protection. The nonces aid in the generations of new key material and the prevention of replay attacks.

The description of a new group only follows phase 1; the ISAKMP SA needs to be established before using New Group Mode. The New Group negotiations specify the characteristics of the group. In some ISAKMP implementations, the private group generated by the New Group Mode can expire with the SA that established it.

Perfect forward secrecy

ISAKMP/Oakley can provide perfect forward secrecy for keys and identities. Both parties to a communication pair would perform the following steps to provide Perfect Forward Secrecy of both keys and all identities:

1. Establish the ISAKMP SA using a Main Mode exchange to protect the identities of the ISAKMP peers.
2. Use a Quick Mode exchange to negotiate other security protocol protection. This establishes a SA on each end for this protocol.
3. Delete the ISAKMP SA and its associated state.

Implementation hints

Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 negotiations extremely quick. As long as you keep the phase 1 state cached you can proceed with phase 2 negotiations without any exponentiation. The number of phase 2 negotiations you can perform based on a single phase 1 depends on the local policy.

Negotiating a range of security associations during Quick mode can speed up re-keying. If a peer feels it is time to change SAs it simply uses the next SA within the stated range.

You can establish SAs with peers before they are needed so they are in place when actually needed. This result in no delays due to key management before initial data transmission. To accomplish set up more than one SA with a peer for each requested Security Association and cache those not immediately used.

Design the implementation so that peers do not respond to informational exchanges. This can help prevent a notify war. A notify war is a condition where a failure to understand a message results in a notify to the peer who cannot understand it and who in turn, sends back its own notify which is also not understood.

Repeated re-keying using Quick Mode can consume the entropy of the Diffie- Hellman shared secret. Set a limit on Quick Mode Exchanges between exponentiations.

SKEME: A versatile secure key exchange mechanism for the Internet

SKEME is a secure and versatile key exchange protocol for key management over Internet. It consists of a compact protocol that supports a variety of security models. The protocol describes a versatile key exchange technique that provides anonymity and repudability. It provides a method of public key encryption for authentication and a method for fast re-keying using an exchange of nonces. SKEME:

• Supports key exchange based on public key, key distribution center or manual installation
• Provides for fast and secure key refreshment.
• Selectively provides forward secrecy
• Allows for replacement and negotiation of underlying cryptographic primitives and addresses privacy issues as anonymity and repudiation.

The protocol and its phases

The SKEME protocol consists of three phases: SHARE, EXCH, and AUTH. In the SHARE phase the communicating parties exchange half-keys. They encrypt these half with a hash function to produce the shared key (KD).

shows the structure of SHARE, EXCH and AUTH.

SKEME uses the EXCH -phase to exchange DH exponents. The protocol accomplishes the authentication of this DH exchange during an AUTH phase. The AUTH phase uses the shared key K0 from SHARE to authenticate 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. FKD provides the functionality of a message authentication.

The SHARE, EXCH, and AUTH phases can be combined unto three messages as shown in Figure Error! No text of specified style in document.-5.

Domain Name System (DNS) Security Extensions

Security extensions to the Domain Name System (DNS) protocol provide a convenient way to access public key information, especially for public keys associated with hosts. RSA keys are a requirement for secure DNS implementations. Extensions to allow optional DSS keys are a possibility. Secure DNS provides an example of authenticating public keys and other resources using a secure directory service.

DNS security extensions make DNS servers CAs for the zones and nodes they serve. DNS provides resource records for public keys and signatures on those keys. The names associated with the keys are IP addresses and domain names which have meaning to entities accessing the DNS for this information.

DNS Security Extensions uses cryptographic digital signatures to provide data integrity and authentication services to resolvers or applications. DNS includes these digital signatures in secured zones as resource records (RR). The DNS security extensions also provide for the storage of authenticated public keys. This key storage can support a public key distribution service along with DNS security.

Security aware resolvers can use these public keys to learn the authenticating key for other zones. In addition, a key associated with DNS names can be retrieved to support other protocols. Secure DNS also supports a variety of key types and algorithms.

DNS security extension services

The DNS protocol security extensions provide three distinct services:

• Key distribution
• Data origin authentication and integrity
• Transaction and request authentication

Key distribution

Resource records (RR's) are defined to associate keys with DNS names. This means you can use DNS as a public key distribution mechanism that supports DNS data origin authentication and other security services. The KEY RR includes an algorithm identifier, the actual public key parameters, and a variety of information flags.

Data origin authentication and integrity

Authentication is provided by associating with RR's in the digital signatures. Typically a single private key signs for an entire zone. If a security aware resolver learns the public key of the zone, it can verify that a signed data read from that zone was properly authorized and is reasonably current. The private key for the zone should be kept off-line used to periodically re-sign the records in the zone. This key is referred to as the data origin authentication key belongs to the zone. It does not belong to the server that stores copies of the data.

A server can learn the public key of a zone by reading it from DNS. The key itself must be signed for a resolver to reliably learn the public key by reading it from DNS. To provide a reasonable degree of security, the resolver must be statically configured with at least the public key of one zone, where it can securely read the public keys of other secure zones.

The data origin authentication service protects retrieved resource records but it does not protect DNS requests or message headers.

DNS transaction and request authentication

Transaction authentication can provide protection for DNS requests or for message headers. By using transaction authentication a resolver can be sure that the:

• Messages are coming from the server it thinks it queried,
• Response is from the query it sent
• Messages have not been altered in transit

Transaction authentication is accomplished by adding a special signature (SIG) record at the end of the reply. The SIG record digitally signs the concatenation of the server's response and the resolver's query. DNS can also authenticate requests by including a special SIG RR at the end of the request. The private keys used in transaction and request security belong to the host composing the request or reply message, not to the zone involved.

The SIG resource record

DNS KEY records have associated SIG records that are signed by a zone authority. A hierarchy of signatures back to the root server establishes a foundation for trust. The SIG records indicate the algorithm used for forming the signature.

Secure DNS uses the SIG record for data authentication. The SIG RR authenticates other resource records of a particular type, class, and name. Using cryptographic techniques and the signer’s private key, DNS binds these resource records to a time interval and the signer’s domain name. The signer is frequently the owner of the zone from which the RR originated.

TIP: Keep zone private keys in off-line and non-network connected physically secure machines. Keep the master copy of the zone file off net. Do not update this file based on an unsecured network communication. Always configure secure resolvers with some trusted on-line public key information.

From Here…

This chapter introduced some certification and key distribution methods, identified some key management issues, and provided a listing of some IPv6 key management requirements. It also described some issues revolving around security implementations for IPv6 and provided a brief overview of some key management protocols

For additional information, you may want to see the following:

• Chapter 15 "Migration Issues" talks about interim options to make the migration from IPv4 to IPv6 smoother
• Chapter 16 "Making the Transition to IPv6" talks about the different transition mechanism to migrate to IPv6 including tunneling, header translation, and upgrade dependencies.
• Chapter 12 "IP Security for IPv6 and IPv4" talks about how the different parts of the IPsec protocol suite work, described how you might use the various IP security mechanisms, and listed some basic IP security requirements.