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.