Course: CS125
Name: Daniel Meredith
Due Date: 01/19/00
Submit Date: 01/19/00
Abstract Title: Internet Key Exchange
Authors: D. Harkins, D. Carrel
Journal Ref: RFC 2409

Security is one area of growing concern on the internet. As more and more transactions are completed online every year the community has no choice, but to question the safety and secrecy of those transactions. The potential for theft and fraud on the internet is huge without the protection of some sort of encryption to insure the safe delivery of data that can only be interpreted by those it was meant for. On that note I chose to follow the IPsec working group for my IETF group and read one of their RFC's for my first abstract.

RFC 2409 is the latest RFC that was posted on the working group's site and seemed to be a good place to start. The document is a proposed standard for Internet Key Exchange or IKE. A very cursory description of the protocol is that it is a simple method of encrypting a data payload for safe transmission over the public internet. The idea of encrypting a piece of data before transmission is not new, but the key feature in this protocol is just that; the key.

Or more correctly, multiple keys. The IKE protocol is set to use multiple encryption key types and algorithms to insure the security of the data packet. The protocol is design to create PFS,or perfect forward secrecy. This is done by using sets of unique keys to encrypt the data. In order for a set of keys to be unique they must all be derived independently. Thus if one of the keys is compromised, the other keys cannot be broken using the compromised key.

The protocol has two phases. In phase 1 the two machines establish a secure path in which to communicate using authentication. This relationship is referred to as a Security Association, or SA. A phase 1 exchange has two main modes, "Main Mode" and "Aggressive Mode". These modes may only be used in phase 1 exchanges. The wording of the RFC complies to the IETF standards and specifics that "Main Mode" MUST be implemented, and that "Aggressive Mode" SHOULD be implemented.

Phase 2 exchanges are negotiated on behalf of other protocols, such as IPsec. Other services also need to use phase 2 exchanges due to their dependacy on key material and parameter negotiation. This type of exchange is referred to as "Quick Mode" and must only be used in phase 2. The is also a "New Group Mode" that is for the expressed purpose of establishing a new group for future negotiations.

The RFC then goes in to detail about how the key packets should be sent and the ordering of the data inside the packets themselves. The protocol lays out every method in which two machines can successfully negotiate a secure channel in which to communicate, and the different keys that must be sent and replied to in a particular way before any part of the data payload may be sent.

This is really the first protocol specification that I have ever read. It seems to be well laid out and progress in a logical manner. I felt that the RFC could have started with a more general tone about how the larger blocks of the protocol fit together without the specification of which key types to use and which Oakley phase would come first. This general overview would have made the paper easier to follow as it became more and more specific. Overall the RFC was to specific to gain a real understanding of how host-server, host-host authentication works, but it does illustrate the intricacies of how a protocol must be designed and laid out.