Part 3 – Standards

This is the third part in a list of cheatsheets based on the book Network Security: Private Communications in a Public World (2nd Edition).

This post is about standards. The first part, Cryptography Introduction Cheatsheet – part 1, was about cryptography and the second part, Cryptography Introduction Cheatsheet – part 2, about authentication.

Kerberos V4

Kerberos is a secret key based service for providing authentication in a network. It uses a KDC on a secure node. A login session is the period between logging in and logging out. The KDC shares a master key (secret key) with each principal (user/resource). When Alice informs the KDC that she wants to talk to Bob a session key is created and she is issued a ticket that is encrypted with the key of Bob (so Alice can not read it). The credentials are the ticket to Bob together with the session key. The KDC also sends a TGT – Ticket Granting Ticket. Because of this, the workstation to which Alice authenticates does not need to continue to remember Alice’s password, it can use the TGT to request access from the KDC to other resources. In theory the TGS Ticket Granting Server could be separate but in Kerberos they are the same thing. The KDC database is protected (encrypted) with a KDC master key. Current implementations of Kerberos use DES.

The login process is as follows

1. Alice types account name and password;
2. The workstation contacts the KDC (clear) with the account name;
3. The KDC replies with credentials (a session key and a ticket granting ticket – this is encrypted with the KDC’s master key, not readable for anyone else than the KDC) for the KDC encrypted with Alice’s master key;
4. The workstation converts the typed-in password to a DES key that is then used to decrypt the received credentials;
5. If successful, the master key is forgotten and only the session key and TGT are remembered.

Note that the TGT is double encrypted; once with the KDC master key, then with Alice’s master key. In Kerberos V4 the user was only requested for the password once the credentials were received (minimal time storage in memory, in V5 the user has to type in the password before the request is send). Once the login process is successful and Alice wants to access a remote node (Bob) this happens

1. The workstation sends to the KDC the TGT, the name “Bob” and an authenticator (this is the time of the day encrypted with the session key);
2. The KDC decrypts the TGT and discovers the session (Sa) key and checks the expiration time in the TGT;
3. The KDC constructs a ticket (a newly generated key (Kab), the name “Alice” and an expiration time) encrypted with the key of Bob. This ticket is then send to the workstation together with the name “Bob” and the new key and encrypted with the session key (Sa);
4. The workstation sends the ticket to Bob;
5. Bob decrypts the ticket and discovers the newly generated key (Kab), he also discovers the time via the decrypted authenticator;
6. Bob increments the time of the authenticator, re-encrypts it with Kab and sends it back to Alice.

Because of the use of (time-based) authenticators it is important to keep workstations time synced. To protect against replays Bob should store recently received timestamps.

One single KDC becomes a single point of failure. Therefore multiple KDCs should be set up. One site holds the master key. This site gets all the updates (modify, delete, …) and other sites download periodically from this site. During the download it is import to protect the data from disclosure or modification.

Realms allows the principals in the network to be divided into “groups” so not all participants have to trust each other. In Kerberos V4 each principal consists of a name, an instance and a realm (each part is 40 chars long, case sensitive, null-terminated). In Kerberos V4 it is not possible to get access through a chain of KDCs.

Each key in Kerberos has a version number to facilitate key changes. Resources should remember several versions of their own keys.

Combined privacy and integrity checks is provided in Kerberos with a modified version of CBC, PCBC – Plaintext Cipher Block Chaining.

In Kerberos V4 the network layer address (IPv4) is put in the ticket to prevent impersonation (and interception). But because it is in the ticket and not in the authenticator it also prevents delegation.

In summary

• A ticket is an encrypted piece of information that is given to principal Alice by the KDC and stored by Alice. It is encrypted by the KDC with Bob’s master key. Alice can not read it but can send it to Bob who can decrypt it;
• An authenticator is a piece of information included in a message at the start of the communication between Alice and Bob which proves both participants to prove that they are who they claim to be. It is encrypted with the session key that Alice requested from the KDC.

Kerberos V5

Kerberos V5 uses ASN.1 syntax with BER – Basic Encoding Rules. ASN.1 is a data representation language standardized by ISO. ASN.1 is more flexible but it adds a lot of overhead. In V4 a principal was named by three fields name, instance and realm). In V5 there are two components : realm and name. The name contains a type and a varying number of arbitrary strings.

Delegation of rights is the ability to give someone else access to things you are authorized to access. Kerberos V5 allows delegation by allowing Alice to ask for a TGT with a network address different from hers. In the request Alice can opt for a different network address or no network address (then it can be used from everywhere). The new TGT as such requested by Alice can not be used by Alice but can be passed to Bob. There is also a possibility to limit the rights

• Rather than giving a TGT, Alice provides Bob tickets to specific services (a TGT allows Bob to ask for every service);
• Alice can request a field AUTHORIZATION-DATA be added to the requested ticket or TGT. This field is then interpreted by the application;

Two flags in a TGT involve delegation permission

• forwardable : the TGT can be exchanged for a TGT with a different network layer address;
• proxiable : the TGT can be used to request tickets for use with a different network layer address.

In V4 the maximum ticket lifetime was about 21 hours. In V5 it can be virtually unlimited. This can pose a security risk. Therefore there is the possibility to have renewable tickets where the KDC sets the RENEWABLE flag inside the ticket. A RENEW-TILL specifies the limit. Alice will have to renew the tickets before expiration (maybe with the use of a daemon). Tickets can also be created postdated with a timestamp (set with START-TIME) in the future. Initially the KDC sets the INVALID flag, when the time in START-TIME occurs Alice can present the ticket and then the KDC clears the INVALID flag.

In V5 the KDC keeps track of multiple key versions to facilitate renewable and postdated tickets. The keys are stored as a triple : key, the version number of the key and the version of number of the KDC key to sign this key (because the KDC can also change keys).

In V4 DES was used as the encryption algorithm. V5 can use different algorithms due to its modular design. For integrity checks, in V5 the MACs (message authentication codes or integrity check or checksum) are rsa-md5-des (required), des-mac (required), des-mac-k (required), rsa-md4-des (optional) and rsa-md4-des-k (optional). For encryption and integrity protection you can use des-cbc-crc, des-cbc-md4 and des-cbc-md5.

With different realms in V4 it was needed that the KDC be registered as a principal in each of them. In V5 you can go through a series of realms to authenticate.

In order to protect better against off-line password guessing when requesting a TGT for another user you must supply PREAUTHENTICATION-DATA to prove that you know the master key of that user.

Kerberos V5 allows Alice to choose a different key for multiple conversations and put that in the authenticator.

PKINIT provides a bridge between public key enabled users and servers that only know secret key technology.

The entries in the V5 KDC database consist of

• name of the principal;
• principal’s master key;
• p_kvno principal’s key version number;
• max_life defines maximum lifetime for tickets;
• max_renewable_life maximum lifetime for renewable tickets;
• k_kvno KDCkey version;
• expiration time when the database entry expires;
• mod_date modification date of entry;
• mod_name name of the last modifier;
• some flags indicating KDC policies;
• password expiration defines time when password expires;
• last_pwd_change time when user last changed password;
• last_successtime of last successful user login.

PKI – Public Key Infrastructure

A PKI – Public Key Infrastructure consists of the components necessary to securely distribute public keys.

• certificates;
• a repository for retrieving certificates;
• a method for revoking certificates;
• a method for evaluating a chain of certificates from public keys that are known and trusted in advance (trust anchors) to the target name.

• A certificate is a signed message vouching that a particular name goes with a particular public key;
• The issuer signs a certificate vouching it is for a particular name and key, the subject;
• The verifier (or relying party) evaluates a chain of certificates;
• Anything with a public key is a principal;
• A trust anchor is a public key that the verifier has decided through some means is trusted to sign certificates.

There are different PKI trust models.

• In the monopoly model one organization is chosen to be the single CA for the world. This has problems because there’s not one organization trusted by everyone, a key change would require all software and hardware to reconfigure and how would they certify a remote requester?
• The monopoly model plus registration authorities (RA) is similar except that the single CA chooses other organizations to securely check identities and obtain and vouch for public keys. It is more convenient than the first model to get certified but all the other disadvantages apply;
• In the delegated CA the trust anchor CA can issues certificates to other CAs. Users do not have to go to a single CA;
• The oligarchy model is commonly used in browsers. The products come configured with many trust anchors and a certificate issued by any one of them is accepted. This is even less secure than a monopoly model because instead of one organization at risk (CA) you now have multiple organizations at risk; the trust anchors are trusted by the vendor (product), not by the user; it might be easy to trick a user into adding a bogus trust anchor; there is no practical way to examine the set of trust anchors;
• The anarchy model is used by PGP. Each user is responsible for configuring some trust anchors and anyone can sign certificates for anyone else. Some organizations provide a database where these certificates are stored. This is unworkable on large scale because the database would get unworkable large and it becomes very complicated to entirely trust the chain of trust anchors.

CAs are bound by name constraints were they can only be trusted for certifying a subset of users.

• Top down name constraints is similar to the monopoly model. It is easy to find the path to a name (follow the namespace from the root) but it has the same issues as the monopoly model;
• Bottom up name constraints model is not deployed although Lotus Notes is close. Every organization creates its own PKI and then link to others.

Revocation is necessary when someone realizes their key has been compromised or if someone leaves an organization. A timestamped CRL lists the revoked certificates.

• A Delta CRL is short (often containing no certificates) containing the revoked certificates since the last full CRL was published;
• The First Valid Certificate is a CRL where periodically users with a serial number lower than n have to reissue a new certificate;
• An OLRS – Online Revocation Server is a system that can be queried about the revocation of individual certificates;
• The Good-lists vs Bad lists model envisions a scheme with lists of valid certificates. The list of good certificates is likely larger so this can have a performance impact.

A PKI can be facilitated by a distributed hierarchical database like DNS or X.500. DNS has captured the low end of functionality where efficiency is needed. Names in a certificate are X.509 containing information such as version, serialnumber, signature (the algorithm used to compute the signature on this certificate), issuer, validity, subject (the X.500 name of the entity whose key is being certified), ….

An ACL – Access Control List defines if users have access to a resource. Instead of listing for each resource the users, you can also have a database containing users listing what they are allowed to do. Groups were introduced to make ACLs more scalable. A role concept defines the different privileges a user gets depending on how the user is logged in.

Real Time Communication Security

An application implemented on Layer 3 (IPSEC) causes all applications to be protected without the applications having to be modified. IPsec implementations, IP can tell the application only the IP address it is talking to, no what user is on the other end.

An application implemented on Layer 4 (SSL/TLS, SSH) is implemented as a user process, no change is needed to the operating system. It requires the application to “interface” to SSL and no to TCP. A downside of this implementation is that if malicious data is inserted into the packet stream, as long as it passes the TCP checks, it will get acknowledged by TCP and passed on to SSL. SSL will reject it. If the packet is resend then TCP will think it is a duplicate.

After the cryptographic mutual authentication it remains important to protect the data from disclosure or modification. Next to this the communication should also be protected against session hijack where someone else takes over a session (by forging one side of the communication).

A protocol has PFS – Perfect Forward Secrecy if it is impossible for an intruder to decrypt a conversation between Alice and Bob, even if the entire encrypted session is recorded and the intruder steals the long-term secret of both Alice and Bob. The trick to PFS is to generate a temporary session key that is not derivable from information stored on the nodes and where the session key is forgotten once the session ends. Protocols with PFS also have escrow-foilage which means that even if Alice and Bob are forced to give their key the conversation can not be read. Note that Kerberos does not have PFS.

A denial of service or clogging protection is the use of cookies (not web browser cookies). A stateless cookie (as in f.e. Photuris) is a cookie that is a function of the IP address and a secret known to Bob.

IPsec

An IPsec SA – security association is a cryptographically protected connection. A cryptographic key and other information (identity of other end, sequence number, cryptographic services used) are associated with the SA. An SA is unidirectional, so for a conversation between Alice and Bob there will always be two SAs. An IPsec header, SPI – Security Parameter Index, identifies the SA, allowing Alice to look up the information in her SA database. The SPI value is chosen by Bob. A IPsec Security Policy Database is a database specifying which type of packets should be dropped, forwarded or accepted without IPsec protection, …

IPsec has two modes

• transport mode where IPsec information is added between the header and the remainder of the packet. Most often used end to end. ( [IP header|packet] -> [IP header|IPsec|packet] );
• tunnel mode keeps the original packet and adds a new IP header and IPsec information (ESP or AH) outside. Most often for firewall to firewall or endnode to firewall. ( [IP header|packet] -> [newIPheader|IPsec|IP header|packet] ). It uses a little bit more space because there are now two IP headers. It is essential between two firewalls to preserve the original source and destination address.

An IPsec tunnel can not go through a NAT – Network Address Translation box because the NAT box wants to update the IP addresses inside the encrypted data … and it does not have the key. Even IPsec transport mode has problems because the IP address is included in the TCP/UDP checksums.

The IPv4 header has a protocol field (tcp=6, udp=17, IP=4). IPsec defines two new values: ESP=50 and AH=51. The IPv6 header equivalent field is next header (with the same values as in IPv4).

There are two types of IPsec headers

• AH – Authentication Header providing integrity protection only;
  • next header (1 octet) is the same as the protocol field in IPv4;
  • payload length (1 octet) size of AH header in 32-bit chunks, not counting first 8 octets;
  • 2 unused octets;
  • SPI (4 octets);
  • sequence number (4 octets), has nothing to do with a TCP sequence number but prevents replayed packets in AH;
  • authentication data that provides a cryptographic integrity check on the data.

  Some fields in an IP header get modified by routers etc. so they can not be included in AH integrity check. These fields are type of service, flags, fragment offset, time to live and header checksum.

• ESP – Encapsulating Security Payload providing encryption and / or integrity protection.
  • SPI (4 octets);
  • sequence number (4 octets), has nothing to do with a TCP sequence number but prevents replayed packets in AH;
  • an IV (initialization vector);
  • the (protected data;
  • some padding;
  • padding length (1 octet);
  • next header / protocol type (1 octet);
  • authentication data is the cryptographic integrity check.

Why would you use AH? AH provides integrity protection for some of the fields in the IP header.

IPsec : IKE

IKE is a protocol for doing mutual authentication and establishing a shared secret key to create an IPsec SA. It’s intent is to do mutual authentication using some sort of long term key (pre shared key, public signature-only key or public encryption key) and establish a session key. The specification of IKE is in three pieces

• ISAKMP – Internet Security Association and Key Management Protocol, RFC 2408
• IKE, RFC 2409;
• DOI – Domain of Interpretation, RFC 2407

Photuris was one of the main candidates for this piece of IPsec. It was basically a signed Diffie-Hellman exchange with identity hiding by first doing an anonymous Diffie-Hellman and using an initial stateless cookie. SKIP – Simple Key Management for Internet Protocols was one of the other candidates.

IKE defines two phases

• Phase 1 (known as ISAKMP SA or IKE SA) does mutual authentication and establishes session keys. It is based on identities (names, secrets such as public key pairs or pre-shared secrets). it hase two modes (the exact mode is chosen by Alice)
  • Aggressive mode uses three messages for mutual authentication and session key establishment;
  • Main mode uses six messages and has the ability to hide endpoint identifiers from eavesdroppers and has additional flexibility in negotiating the crypto algorithms.

  The Phase 1 establishes 2 session keys : an integrity key and an encryption key (integrity protecting and encrypting the last of the pase 1 IKE messages and all phase 2 IKE messages).
  IKE Phase 1 supports these protocols

  • Public Signature Keys, Main Mode;
  • Public Signature Keys, Aggressive Mode;
  • Public Encryption Key, Main Mode, Original;
  • Public Encryption Key, Aggressive Mode, Original;
  • Public Encryption Key, Main Mode, Revised;
  • Public Encryption Key, Aggressive Mode, Revised;
  • Shared Secret Key, Main Mode;
  • Shared Secret Key, Aggressive Mode.
• In Phase 2 an ESP or AH SA is established. IPsec allows that each side of a phase 2 SA restricts the traffic sent on that SA (IP address, protocol, type and/or port). It is done by having the phase 2 initiater propose a traffic selector.

Phase 2 IKE (Quick Mode) is a 3-message protocol that negotiates parameters (cryptographic parameters, the SPI, …) for the Phase 2 SA. All messages are encrypted with Phase 1 SA’s encryption key and integrity protected with Phase 1 SA’s integrity key.

ISAKMP/IKE messages have a fixed header and then a sequence of payloads. Similar to IPv6, each payload starts with TYPE OF NEXT PAYLOAD and LENGTH OF THIS PAYLOAD. Some of the different payload types are

• SA – Security Association, this includes the P and T payloads;
• P – Proposal : indicates what “protocol” you’re trying to negotiate (Phase 1 IKE, ESP, AH);
• T – Transform : indicates a complete suite of cryptographic algorithms needed by P. Each P contains a set of Ts;
• … ;

SSL/TLS

SSL/TLS allows two parties to authenticate and establish a session key that is used to cryptographically protect the remainder of the discussion. It is designed to run in a user-level process and runs on top of TCP. A basic overview of the protocol is

1. Alice sends Bob a list of cryptographic algorithms that she supports and sends a random number Ralice;
2. Bob sends Alice his certificate, a random number Rbob and a selection of one of the ciphers;
3. Alice sends to Bob a random number S (pre-master-secret) encrypted with his public key, a hash of the master secret K and the handshake messages;
4. Bob replies with a keyed hash of all the handshake messages, encrypted and integrity protected with his keys. Since the session keys are derived from S he proves he has access to the private key because he needed it to extract S.

Often there’s no mutual authentication (Alice knows she’s talking to Bob but Bob has no clue). SSL/TLS allows session resumption (and so skipping the public key portion of the handshake) if Alice sends a session_id that Bob remembers.

A cypher suite is a complete package (encryption algorithm, key length, integrity checksum algorithm). In SSLv2 Alice decides the suite (Alice sends, Bob replies with what he supports from Alice and then Alice chooses). In SSLv3 Bob makes the choice from the list of Alice.

SSL/TLS runs on TCP so TCP will handle breaking the messages up in packets and reassembling them. SSL/TLS has two layers of chunking which operate somewhat independently

• The unit of cryptographic protection is the record (header + body). There are four record types
  • 20=ChangeCihperSpec (is really part of the handshake). It indicates that all records following this will be protected by the agreed on ciphers;
  • 21=alert , indicating the other side something went wrong (1=warning, 2=fatal);
  • 22=handshake. This record contains handshake messages : ClientHello, ServerHello, ServerHelloDone, ClientKeyExchange, ServerKeyExchange, CertificateRequest, Certificate, CertificateVerify, HandshakeFinished;
  • 23=application data;
• The parts of the handshake are divided into messages (header + body).