This is basically just notes, I will probably add more from time to time, if there is anything that you think should be added, then please use the comment boxes below.
2.0 Security Protocols
2.1 RSA
One of the first public-key cryptosystems. Uses two keys, one is public (the encryption key), the other is private (the decryption key). This is asymmetric. User creates (and publishes) a public key. Relatively slow. Key sizes are from 1024 to 4096.
RFC 2409 restricts private key size to 2048 bits or less for RSA encryption. Recommended modulus value for CA (and clients) is 2048 bits.
4 steps - Key generation, key distribution, encryption and decryption.
RSA & PKI -
PKI:
- Certificate Authority - issues and verifies digital certificates
- Registration Authority - verifies identify of users requesting information from CA - also called a subordinate CA, accepts requests for certificates and authenticates the requester.
- Central Directory - secure location to store and index keys
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_pki/configuration/xe-3s/sec-pki-xe-3s-book/sec-deploy-rsa-pki.html
RSA key pair (public & private) required before you can obtain a certificate for your router. End host must generate pair of RSA keys and exchange public key with the CA to obtain a certificate and enrol in PKI.
A CA (Certificate Authority), which is a trustpoint, manages certificate requests and issues certificates. CA generates its own public key pair and creates a self-signed CA cert, The CA can then sign certificates and begin peer enrolment for the PKI.
RSA key pairs may need to be removed if:
During manual PKI operations and maintenance the old RSA keys can be removed and replaced with new keys
Existing CA is replaced and the new CA requires newly generated keys - i.e key size may have changed from 1024 to 2048.
Peer route's public keys can be deleted in order to debug signature verification problems in IKEv1 and IKEv2.
2.2 RC4
Stream cipher, simple and fast (about 10 times faster than DES for example), though insecure. Vulnerable when beginning of output stream is not discarded - lead to inscure protocols such as WEP. RFC 7465 prohibits use of RC4 in TLS. Generates a pseudo-random stream of bits. Generates keystream through a permutation of all 256 possible bytes (which is a variable length key, typically between 40 and 256 bits), also uses two 8-bit index pointers.
2.3 MD5
Hashing function - replaces MD4, made by Ron Rivest who created RC4. Creates a digest of 128-bits. No longer recommended as vulnerable. Hashing functions take input data and return a hash function (called hash or digest). Input and message has one-to-one mapping. Hashes are one-way - can create a digest, but cannot create original data from a digest.
2.4 SHA
Multiple variants.
SHA-0 - 160-bit hash, not widely used
SHA-1 - 160-bit hash, correct issues with SHA-0. Widely used but not recommended as there are theoretical attacks
SHA-2 - creates hashes of 224, 256, 384 or 512 bits.
SHA-224, SHA-256, SHA-384, SHA-512, SHA-512.224 & SHA-512/256
SHA-512 used by TRueCrypt
SHA-256 used by DKIM signing
SHA-256 and SHA-512 recommended for DNSSEC
SHA-3
2.5 DES
Block cipher, considered insecure - small key-size of 56-bits
2.6 3DES
Applies DES algorithm three times, better practical security, 3 keys of 56-bits each.
2.7 AES
Block cipher, successor to DES. based on Rijndael cipher. Most CPUs include hardware AES support - making it fast. Supported by TrueCrypt & SSH
2.8 IPsec
Protocol suite authenticates and encrypts each IP packet. Uses Security Associations (SA) - a bundle of algorithms and parameters used to encrypt and authenticate a particular flow in one direction - in bi-directional traffic the flows a rescured by a pair of SAs.
Uses ISAKMP to establish the SAs.
IPSec adds an overhead to the packet - meaning packet may need to be fragmented. By default the router knows the IPSec overhead to add to the packet, it then performs a lookup to see if the packet will exceed the egress physical interface IP MTU after encryption has been applied. If this is the case it then fragments the packet before encrypting it, and separately encrypts the resulting IP fragments.
2.9 ISAKMP
RFC 2408. Establishes Security Associations. UDP port 500
2.10 IKE and IKEv2
Phase 1: Uses Diffie-Hellman key exchange to generate a shared secret to encrypt further IKE communications. Results in one single bi-directional ISAKMP SA. Can use pre-shared key, signatures of PKI. Operates in Main mode or Aggressive mode. Main protects identity of peers, aggressive does not.
Phase 2: IKE peers use secure channel to negotiate SAs on behalf of other services, like IPSec. Results in minimum of two unidirectional SAs (one inbound one outbound). Operates in Quick Mode only.
IKEv2 0 adds standard mobility support, NAT traversal (encapsulation of IKE and ESP in UDP port 4500, SCTP support (VoIP), reliability and state management, It is DoS resilience.
2.11 GDOI
http://www.cisco.com/c/en/us/products/security/group-encrypted-transport-vpn/index.html
http://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html
http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf
Group Domain of Interpretation - cryptographic protocol used for key management. RFC 6407. Based on ISAKMP and IKEv1.
It is run between group member(s) and group controller (key server). Uses IKEv1 Phase 1 SA for authenticating a GDOI member to a GDOI controller, protecting a new phase 2 exchange where a member pulls the group state from the controller.
Group key encrypts keys that decrypt application data. The group key is also called a key encrypting key (KEK). KEK is used for Rekey Security Association - once Rekey-SA is established the GDOI controller can push unsolicited updates to the group security association to members over multicast, broadcast or unicast. GDOI is referred to as a multicast key management system.
2.12 AH
AH - provides connectionless integrity and data origin authentication for IP datagrams - computed authentication data is sent to peer.
IPv4 - protects payload and all header fields (except mutable fields - those that might be altered in transit)
IPv6 - protects most of IPv6 base header, AH itself, non-mutable extension headers after the AH and the IP payload.
Uses IP protocol 51.
Packet format:
Next Header | Payload Len | Reserved protected.
Security Parameters Index (SPI)
Sequence Number
Integrity Check value (ICV)
Next header indicates what upper-layer protocol is
SPI identifies the Security Association of the receiving party
Sequence number is used for protection against anti-replay attacks, sequence numbers are never reused.
DH Does not provide data authentication
2.13 ESP
Provides confidentiality, data origin authentication, connectionless integrity and anti-replay.
2 modes: Transport mode (does not provide integrity and authentication for entire IP packet) & tunnel mode (does provide the above).
Uses IP protocol 50.
Packet format:
Security Parameters Index (SPI)
Sequence number
Payload data
Padding | padd length | next header
Integrity Check Value (ICV)
2.14 CEP
Certificate Enrollment Protocol. SCEP Simple Certificate Enrollment Protocol used for enrollment and other PKI operations. Based on HTTP, Only supports RSA-based cryptography.
Steps:
Obtain copy of CA cert and validate it
Generate CSR and send to CA
Poll SCEP server to check if cert gets signed
Re-enroll as necessary
Retrieve CRL
2.15 TLS and DTLS
Preferred over SSL. Uses private and public keys and certificates. Provides privacy and data integrity between two communicating applications, Private as uses symmetric cryptography. Keys are generated uniquely for each connection - based on a secret negotiation at the start of the session. Server and client negotiate details of encryption and cryptographic keys to use before first byte of data is transmitted. Identity of parties can be authenticated using public key cryptography. Uses Message Authentication Code (MAC) to ensure reliability.
Client connects to TLS enabled server, requesting a secure connection, presents a list of supported cipher suites.
Server picks a cipher and hash that it supports and notifies client of decision.
Server sends its digital certificate (server name, trusted CA and public encryption key)
Client may then contact issing CA confirming validity of certificate
Client then generates session keys - either through random number encryption with servers public key or uses Diffie-Hellman key exchange
TLS 1.0 - RFC 2246
TLS 1.1 - RFC 4346 - added protection against cipher-block chaining (CBC) attacks, support for IANA registration of parameters
TLS 1.2 - RFC 5246 - replaced MD5-SHA1 with SHA-256
TLS 1.3 - draft - removes weak elliptic curves, removes MD5 & SHA-224
DTLS - Datagram Transport Layer Security - allows datagram-based applications to be secure. Based on TLS. RFC 6347. Used by AnyConnect.
2.16 SSL
Now deprecated
2.17 SSH
http://www.snailbook.com/faq/ssh-1-vs-2.auto.html
Encrypted network protocol for remote login. Uses public-private key pairs, and password. Can also just use manually created public-private key pair (no need for password)
SSHv1 / SSHv2:
Both require a server key to protect the session key
SSHv2 has different layers:
Transport layer - RFC 4253 - handles initial key exchange, server authentication, encryption, compression and integrity validation. Exposes an interface for sending and receiving plaintext packets - also does key re-exchange afte 1GB or 1hour.
User Authentication layer - RC 4252 - handles client authentication - provides a number of authentication methods, client driven - can use password, publickey, keyboard-interactive, GSSAIP
Connection layer - RFC 4254 - can host multiple channels such as shell, direct-tcip (client-to-server), forwarded-tcpip (server-to-client)
SSHFTP DNS record (RFC 4255) provides public host fingerprints to aid verification of authenticity of host.
2.18 RADIUS
Centralized AAA, uses UDP at application layer. Often backend choice for 802.1X. Can use PAP, CHAP or EAP as authentication, can also connect to SQL, Kerberos, LDAP or AD.
Access-Request
Access-Accept
(or Access-Reject or Access-Challenge)
Reject - user unconditionally denied access - user unknown or user inactive
Challenge - request additional information - such as secondary password, PIN, token or card
Accept - granted access.
Authorization attributes can be included (giving extra rights) - can request IP address, L2TP parameters or VLAN parameters or QoS params.
Uses RSA MD5 to hide passwords.
Attribute value Pairs (AVP) are string values.
RADIUS does not encrypt username, authorization,or accounting
2.19 TACACS+
Cisco proprietary. remote authentication and related services for network access control through centralized server. Uses TCP. Encrypts all information (unlike Radius)
2.20 LDAP
Vendor neutral protocol for accessing and maintaining distributed directory services over an IP network. latest version is 3 - RFC 4511.
Common usage is in SSO (Single Sign On). Based on X.500. Uses TCP/UDP 389 or 636 (LDAPS). Global catalog on port 3268 & 3269. LDAPv3 can use TLS.
2.21 EAP methods (for example, EAP-MD5, EAP-TLS, EAP-TTLS, EAP-FAST, PEAP, and LEAP)
Extensible Authentication Protocol - RFC 3748 (made RFC 2284 obsolete), updated by RFC 5247. Provides transport and usage of keying material and parameters generated by EAP methods.
LEAP (Lightweight EAP) - developed by Cisco. Uses modified version of MS-CHAP - not strongly protected easily compromised. Not recommended
EAP-TLS - RFC 5216 - Still considered secure, requires client-side X.509 certificate
EAP-MD5 - RFC 2284 - minimal security, vulnerable to dictionary attacks, does not support key generation. Unsuitable for use w/ dynamic WEP or WPA/WPA2 enterprise. Only provides authentication of EAP peer to EAP server, but not mutual authentication. Vulnerable to MITM attacks.
EAP-POTP - protected one-time password - RFC 4793 - uses OTP tokens, Can provide unilateral or mutual authentication. 2 factor.
EAP-PSK - RFC 4764 - used pre-shared key.
EAP-PWD - RFC 5931 - shared password
EAP-TTLS - Client can be authenticated via a CA-signed PKI certificate to the server. Server can then use a tunnel to authenticate the client.
EAP-IKEv2 - RFC 5106 - based on IKEv2 - mutual authentication and session key establishment.
EAP-FAST - RFC 4851 - replacement for LEAP. Uses Protected Access Credential (PAC) to establish TLS tunnel. 3 phases
0 - in-band provisioning - provide shared secret, uses authenticated Diffie-Hellman Protocol (ADHP)
1 - tunnel establishment - authenticates using PAC, establishes tunnel key
2 - authentication - authenticates peer
Use manual PAC provisioning as automatic is vulnerable to attacker intercepting the PAC. PAC is issues on per-user basis, new user = need to create new PAC first.
EAP only defines message formats - needs to use another way to encapsulate
802.1X - EAP over LANs (EAPOL) - can use TKIP or CCMP (based on AES)
PEAP - (Protected EAP) - encapsulates EAP within TLS.
2.22 PKI, PKIX, and PKCS
PKIX
Also known as X.509, ITU-T standard for PKI and PMI. Specifies standard formats for public key certificates, certificate revocation lists (CRL), attribute certificates, and a certification path validation algorithm.
CA issues certificate binding public key to a particular distinguished name, or to an alternative name. Root certificates can be distributed so that they trust the PKI system.
X.509 includes certificate revocation list. IEFT-approved is OCSP (Online Certificate status Protocol)
V3 digital certificate structure:
Certificate
Version number
Serial number
Serial Algorithm ID
Issuer name
Validity period
Not before
Not after
Subject name
Subject public key info
Public Key Algorithm
Subject Public Key
Issuer Unique Identifier (optional)
Subject Unique Identifier (optional)
Extensions (optional)
Certificate Signature algorithm
Certificate signature
Formats:
.pem - privacy-enhanced Electronic Mail - encoded DER cert
.cer, .crt, .der - usually in binary DER form - can also Base64-encode
.p7b, .p7c - PKCS#7 SignedData structure w/out data, just certs of CRLs
.p12 - PKCS#12 - may contain certificates, public and private keys (password protected)
.pfx - predecessor of PKCS#12
PKCS - RSA
Group of public-key cryptographic standards created by RSA Security Inc. - Designed to promote use of cryptographic techniques using RSA patents.Covers PKCS#1 - 15.
2.23 IEEE 802.1X
IEEE standard, port-based Network Access Control (PNAC). Provides authentication to devices connecting to LAN or WLAN. Uses EAP over 802 - EAP over LAN or EAPOL.
3 parties - supplicant, authenticator and authentication server.
Supplicant - client device - but also refers to the software used to connect to authenticator
Authenticator - network device (such as switch or AP)
Authentication server - RADIUS & EAP (like ISE)
Process:
Initialization - switch port is set to unauthorised state - only 802.1X traffic is allowed - other traffic, such as IP (including TCP & UDP) is dropped.
Initiation - authenticator transmits EAP-Request Identify frames. Supplicant listens, will respond with EAP-Response Identify frame, containing identifier (i.e. User ID). Authenticator encapsulates this in a RADIUS Access-Request and forwards on to the authentication server
Negotiation - Authentication Server sends a RADIUS Access-Challenge to the authenticator, containing EAP Request with EAP method. Authenticator encapsulates the EAP Request in EAPOL frame and transmits to supplicant. Supplicant can either use this, or NAK and respond with supports EAP methods to use.
Authentication - If authentication server & supplicant agree on an EAP method and authenticity is successful then the authenticator sets port to authorised and normal traffic is allowed.
MAB - MAC Authentication Bypass - used where device not 802.1X compatible - When configured port will first check to see if device is 802.1X compliant - if not will then try to authenticate to AAA server using connected devices MAC address as username and password.
2.24 WEP, WPA, and WPA2
WEP - Wired Equivalent Privacy - for 802.11 wireless networks. Now deprecated (as of 2004). Uses RC4 (confidentiality) and CRC-32 (integrity). 64-bit WEP uses 40-bit key and 24-bit IV
WPA - Wi-Fi Protected Access (and WPA2) - uses TKIP (Temporal Key Integrity Protocol) and supports CCMP - an AES-based encryption mode.
TKIP has a 64-bit Message Integrity Check (MIC) and uses a new 128-bit key for each packet. implements key mixing function - combines secret root key with the IV before passing it to RC4.
WPA-Personal - uses pre-shared key
WPA-Enterprise - requires RADIUS server
2.25 WCCP
Web Cache communication protocol - Cisco developed protocol for content-routing. Redirects traffic in real-time, built in load balancing, scaling, fault tolerance, and service-assurance. Can also be used for traffic localisation.
WCCPv1 - only single router services a cluster of systems, supports HTTP only, uses GRE, uses UDP/2048
WCCPv2 - can use 32 routers with 32 engines/accelerators, supports any IP protocol (including multicast), supports 255 service groups, adds MD5 shared secret security (authentication)
client sends “Here I am” every 10 seconds
Server acknowledges with “I See you”
2.26 SXP
Part of TrustSec - enables security through identity-based controls. “anyone, anywhere, anytime”. data integrity and confidentiality services, policy-based governance and generalised monitoring, troubleshooting and reporting.
Establishes domains of trusted networks, each device being authenticated by its peers. packets are classified by security groups (SGs). Classification maintained by tagging packets on ingress - called Security Group Tag (SGT).
Uses SGT Exchange Protocol (SXP) to propagate SGts.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_cts/configuration/xe-3s/sec-usr-cts-xe-3s-book/cts-sxp-ipv4.html
2.27 MACsec
802.1AE aka MACsec - connectionless data confidentiality and integrity for media access independent protocols. New frame type, includes new fields - Security tag and Message Authentication Code. default cipher suite of GMC-AES-128, and GMC-AES-256.
Allows authorised Lan connections to be identified and excluded from communication within the network. Can mitigate attacks on L2 protocols.
2.28 DNSSEC
Domain Name System Security Extensions - provides origin authentication of DNS data, denial of existence, and data integrity. Designed to protect against cache poisoning, uses digital signatures. New DNS record types:
RRSIG - record set
DNSKEY - contains public key that DNS resolver uses to verify DNSSEC in RRSIG-records
DS - name of delegated zone
NSEC - link to next record name
NSEC3 - links to next record name in hash
NSEC3PARAM - authoritative DNS servers