Report
Upcoming SlideShare
Loading in...5
×
 

Report

on

  • 391 views

 

Statistics

Views

Total Views
391
Views on SlideShare
391
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Report Report Document Transcript

  • CmpE 208: Network Architecture and Protocols ISAKMP Submitted by Group: A Piece of Cake Gary Aoki Linan Chang Thu Nguyen Pravesvuth Uparanukraw Due Date: 8 November, 2006
  • Table Of Contents 1.Introduction ...............................................................................................3 2.Authentication............................................................................................3 2.1.Authentication with Digital Signatures......................................................................3 2.2.Authentication with Public Key Encryption..............................................................3 2.3.Revised Authentication with Public Key Encryption................................................4 2.4.Authentication with a Pre-Shared Key......................................................................4 3.Key Generation and Management............................................................4 4.Security Associations..................................................................................4 5.Architecture................................................................................................5 5.1.Header Format...........................................................................................................5 5.2.Payload Types............................................................................................................7 5.3.Exchange Types.........................................................................................................7 5.4.Policy Negotiation.....................................................................................................8 6.Security Issues............................................................................................8 6.1.Man-In-The-Middle Attack.......................................................................................8 6.2.Denial of Service Attack............................................................................................8 6.3.Replay Attack.............................................................................................................8 6.4.Hijacking Attack........................................................................................................9 7.Features and Benefits.................................................................................9 8.Conclusion...................................................................................................9 9.Abbreviations..............................................................................................9 10.References...............................................................................................10 2
  • 1. Introduction The Internet Security Association and Key Management Protocol (ISAKMP) is designed to establish secure communication connections over the Internet. ISAKMP defines the procedures for authentication, key management, and creation and management of Security Associations. Authentication is the process of determining the identity of a user. Key management is the process of creating, distributing and maintaining encryption keys. The methods and formats for packaging and transferring keys and authentication data are independent of the key generating methods and encryption algorithms. There may be many different key exchange protocols, each with different security properties. Security Associations (SA) define the relationship between two or more entities and describe how the entities will utilize security services. ISAKMP provides a common framework for negotiating, modifying and deleting SAs. By centralizing the management of the Security Associations, it reduces the amount of duplicated functionality within each security protocol and also reduces the connection setup time by negotiation the whole stack of services at once. All of these services are necessary to establish and maintain secure communications over the Internet. However, these services are separate in functionality to allow for interoperability between systems with differing security requirements. ISAKMP is described in the Internet Engineering Task Force Request for Comments (RFC) 2048. 2. Authentication There are two general categories of authentication mechanisms: strong and weak. Weak authentication occurs when clear-text keys or other unprotected information is sent over the network. Strong authentication is achieved via digital signatures or public/private key encryption. ISAKMP must provide support for strong authentication. ISAKMP does not require a specific certificate authority. The initiating entity indicates which CAs it supports. After the selection of a CA, the protocol defines the messages required to support authentication. 2.1.Authentication with Digital Signatures This authentication can be used in either main mode or aggressive mode. In both modes the signed data is the result of the negotiated signature algorithm applied to a hash function. 2.2.Authentication with Public Key Encryption Public key encryption increases the total security since an attacker would have to break not only the Diffie-Hellman exchange but also both RSA encryptions. There is no proof 3
  • that the negotiation ever took place since each party can reconstruct both sides of the exchange. Additional benefit is that authentication with public key encryption allows identity protection even with aggressive mode. In order to perform the public key encryption, the initiator must have the responder's public key. If the responder has several public keys, a hash of the public key being used is transmitted to the responder. With this hash the responder can select the corresponding private key. The authentication message contains encrypted identities of the parties and the usual nonce. The payload headers are, however, not protected with encryption. 2.3.Revised Authentication with Public Key Encryption In this mode the nonce is still encrypted with the public key encryption but the peer's identity is encrypted using the negotiated symmetric encryption algorithm. The key is derived from the nonce. This mode retains the advantages of public key authentication but with half the public key operations. 2.4.Authentication with a Pre-Shared Key When authenticating with pre-shared keys both parties must communicate and agree upon a key using a (probably) insecure medium. The key is distributed in an out-of-band fashion. IETF IPSEC defines a 14-byte pre-shared key for the Internet Protocol. 3. Key Generation and Management The Diffie-Hellman algorithm is an example of secure key generation and exchange. The benefit of this algorithm is that the key is based on public and secret information held by both users, and the key is independent from one session to another. An example of key exchange is with the use of the RSA encryption. A secret, random session key is generated by the sender and encrypted using the recipient’s public key. The encrypted session key is then sent to the recipient, who decrypts it using his private key. Key exchanges can be authenticated during the protocol by having each party encrypt known data. Key exchanges can be authenticated after completion of the protocol through subsequent message exchanges. It is preferable to authenticate the key exchange during the protocol. 4. Security Associations ISAKMP uses SAs to support the negotiation of security protocols at all layers of the network stack. They support different authentication methods, key establishment algorithms, encryption algorithms and certificates. An SA describes the relationship between two or more entities and how the entities will use security services. The relationship is represented by information that is agreed on and shared between all participating entities. Each entity must adhere to the SA to support secure communications. 4
  • 5. Architecture All messages in ISAKMP consist of an ISAKMP header followed by one or more payloads. The header has a fixed format, which simplifies parsing and makes implementation easier. 5.1.Header Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Initiator ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Responder ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Initiator cookie (8 bytes): Cookie of the entity that initiated SA establishment, SA notification, or SA deletion. Responder Cookie (8 bytes): Cookie of the entity that is responding to an SA establishment request, SA notification, or SA deletion. Next Payload (8 bits): Indicates the type of the first payload in the message. Value Description References 0 None 1 Security Association RFC 2408 2 Proposal RFC 2408 3 Transform RFC 2408 4 Key Exchange RFC 2408 5 Identification RFC 2408 6 Certificate RFC 2408 7 Certificate Request RFC 2408 8 Hash RFC 2408 9 Signature RFC 2408 10 Nonce RFC 2408 11 Notification RFC 2408 12 Delete RFC 2408 13 Vendor ID RFC 2408 14 15 SAK, SA KEK Payload RFC 3547 16 SAT, SA TEK Payload RFC 3547 5
  • 17 Key Download RFC 3547 18 Sequence Number RFC 3547 19 Proof of Possession RFC 3547 20 NAT-D, NAT Discovery RFC 3947 21 NAT-OA, NAT Original Address RFC 3947 22-127 128-255 Private use Major Version (4 bits): The major version of the ISAKMP protocol in use. Minor Version (4 bits): The minor version of the ISAKMP protocol in use. Exchange Type (8 bits): Value Description 0 None 1 Base 2 Identity protection 3 Authentication only 4 Aggressive 5 Informational 6-31 ISAKMP future use 32-239 DOI specific use 240-255 Private use Flags (8 bits): Indicates the options that are set for the ISAKMP exchange. 0 1 2 3 4 5 6 7 A C E A = Authentication only. 1 bit. Intended for use with the Informational Exchange with a Notify payload and will allow the transmission of information with integrity checking, but no encryption. C = Commit. 1 bit. Used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. E = Encryption. 1 bit. If set, all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA. Message ID (4 bytes): A unique value used to identify the protocol state during Phase 2 negotiations. It is randomly generated by the initiator of the Phase 2 negotiation. Length (4 bytes): The total length of the ISAKMP header and the encapsulated payloads in bytes. 6
  • 5.2.Payload Types All ISAKMP payloads begin with the same generic payload header. Payloads may be “chained” together, with the payload header clearly defining the payload boundaries. • Security Association (SA) payload. Defines the Domain of Interpretation (DOI) and the Situation. • Proposal (P) payload. Describes the security mechanisms which will be used to secure the communications channel. • Transform (T) payload. Describes the specific security mechanisms to be used to secure the communications channel. • Key Exchange (KE) payload. Describes the key exchange protocol to be used and the data required to generate a session key. • Identification (ID) payload. This payload is used to exchange identification information used to determine the identities of communicating peers. • Certificate (CERT) payload. The certificate payload is used to transport certificates or certificate-related information. • Certificate Request (CR) payload. The certificate request payload is used when requesting certificates. • Hash (H) payload. The hash payload contains data generated by the hash function. • Signature (SIG) payload. The signature payload contains data generated by the digital signature function. • Nonce (NONCE) payload. The nonce payload contains random data. • Notification (N) payload. The notification payload can be used to transmit informational data such as error codes and status information to peer entities. • Delete (D) payload. Contains a protocol-specific security association identifier that the sender has removed from its database and is invalid. 5.3.Exchange Types • The Base Exchange allows the key exchange and authentication information to be transmitted together in one message. This reduces the number of round-trips at the expense of security. This does not provide identity protection because they are exchanged before a common shared secret has been established. • The Identity Protection Exchange separates the key exchange from the identity and authentication related information to provide identity protection. This adds two additional messages but identities are exchanged under the protection of a previously established common shared secret. • The Authentication Only Exchange allows only the authentication related information to be transmitted. This means that none of the transmitted information will be encrypted, it is just authenticated. Use of this method saves computational capacity since no encryption keys needs to be calculated. • The Aggressive Exchange allows the security association, key exchange and authentication related information to be transmitted together. This reduces the amount of messages into one, but at the expense of not providing identity protection. 7
  • • The Informational Exchange is a one-way information transmission packet for security association management. If the Informational Exchange occurs prior to the exchange of keying material there will be no protection for this exchange. In later phases the information is transmitted under the protection provided by the keying material or the SA. 5.4.Policy Negotiation There are two phases of ISAKMP policy negotiation. In phase one, two entities negotiate and establish an ISAKMP SA. The ISAKMP SA is then used to protect the negotiations for a Protocol SA. In phase two, the two entities negotiate SAs for other security protocols. The SAs created during this phase can be used to protect many messages and data exchanges. Requiring two phases to negotiate and establish the security protocols results in greater start-up costs. However, the cost of the first phase can be amortized over several phase two negotiations. Additionally, the ISAKMP SA provides encryption to protect the identities of the parties, allowing potentially simpler phase two negotiations. 6. Security Issues 6.1.Man-In-The-Middle Attack Man-In-The-Middle attack is a situation where a bad guy sits between communicating parties (A and B) on the network and intercepts traffic. The man in the middle acts as B to A and as A to B and relays traffic between them. The man in the middle could also modify, delete or insert traffic. Solutions: The linking of ISAKMP exchanges is designed to prevent insertion of messages. The deletion of messages will cancel the creation of SA so partial SA won't be created. Strong authentication of the parties prevents the risk of establishing a SA with other than intended party. 6.2.Denial of Service Attack A denial of service attack is clogging a server with requests for protected computer resources requiring CPU intensive operations. This reduces the amount of CPU resources available to accommodate user’s requirements. Solutions: The public key operations used to authenticate a user are CPU intensive. Instead of authenticating a user for every access to computer resources, a cookie or anti- clogging token is used to authenticate the user. 6.3.Replay Attack Replay or Reflection attack is a situation when a third party records network traffic and replays it. 8
  • Solution: ISAKMP sets requirement for cookies to include a time variable material which eases detection of replay. 6.4.Hijacking Attack This is a situation where a third party jumps in the middle of a transaction and steals the connection. Solutions: IKE is protected from connection hijacking by linking the authentication, key exchange, and security association exchanges. The linking of exchanges prevents a third party attacker from jumping in after authentication and acts as one of the authenticated parties during key exchange or security association exchange. 7. Features and Benefits ISAKMP provides nice features such as: • A fixed field header that contains no security attributes making header parsing consistent and migration to new security attributes easier. • Replay prevention using a time variant cookie. • Initialization exchange to indicate base KMP transform or select other KMP transforms to protect SA and session key establishment. • Strong authentication mechanism required. • Support for multiple certificate authorities. • Transport protocol independence. 8. Conclusion The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for managing Security Associations between different entities on a network. The Security Association (SA) feature, coupled with authentication and key establishment, provides the security and flexibility that is needed for the future growth and diversity of the Internet. Multiple key exchange techniques, encryption algorithms and other security parameters allow users to select the appropriate security for their network communications. However, several exploits and security problems have been discovered in ISAKMP. ISAKMP is vulnerable to denial of service attacks, interoperability issues and privacy information leaking issues. Many of these issues stem from fundamental design flaws and would require significant protocol changes to fix. ISAKMP has been superseded by the Internet Key Exchange Protocol version 2. 9. Abbreviations DOI - Domain of Interpretation GDOI - Group Domain of Interpretation IKE - Internet Key Exchange IPSEC - Internet Protocol Security ISAKMP - The Internet Security Association and Key Management Protocol 9
  • SA - Security Association UDP - User Datagram Protocol 10.References 1. http://en.wikipedia.org/ 2. http://www.ietf.org/rfc/rfc2408.txt 3. http://www.javvin.com/protocolISAKMP.html 4. http://home1.gte.net/res0psau/ipsec-parameters/default-isakmp-ipsec-params.html 5. http://monkey.org/openbsd/archive/tech/9912/msg00215.html 10