Authentication applications – Kerberos, X.509, PKI – Electronic Mail security – PGP, S/MIME – IP security – Web Security – SSL, TLS, SET.

1. IT2352 CRYPTOGRAPHY AND
NETWORK SECURITY
UNIT – IV
Dr.A.Kathirvel, Professor and Head, Dept of IT
Anand Institute of Higher Technology, Chennai

2. UNIT - IV
Authentication applications – Kerberos, X.509, PKI –
Electronic Mail security – PGP, S/MIME – IP security –
Web Security – SSL, TLS, SET.

3. AUTHENTICATION APPLICATIONS
• will consider authentication functions
• developed to support application-level
authentication & digital signatures
• will consider Kerberos – a private-key authentication
service
• then X.509 directory authentication service

4. 4
KERBEROS
• Part of project Athena (MIT).
• Trusted 3rd party authentication scheme.
• Assumes that hosts are not trustworthy.
• Requires that each client (each request for service)
prove it’s identity.
• Does not require user to enter password every time a
service is requested!

5. 5
KERBEROS DESIGN
• User must identify itself once at the beginning of a
workstation session (login session).
• Passwords are never sent across the network in
cleartext (or stored in memory)

6. 6
KERBEROS DESIGN (CONT.)
• Every user has a password.
• Every service has a password.
• The only entity that knows all the passwords is the
Authentication Server.

7. 7
ServerServerServerServer
Kerberos
Database
Ticket Granting
Server
Authentication
Server
Workstation
Kerberos Key Distribution Service

8. 8
SECRET KEY CRYPTOGRAPHY
• The encryption used by current Kerberos
implementations is DES, although Kerberos
V5 has hooks so that other algorithms can
be used.
encryption
plaintext ciphertext
key
ciphertext plaintext
decryption

9. 9
Tickets
• Each request for a service requires a ticket.
• A ticket provides a single client with access to
a single server.

10. 10
TICKETS (CONT.)
• Tickets are dispensed by the “Ticket Granting
Server” (TGS), which has knowledge of all the
encryption keys.
• Tickets are meaningless to clients, they simply
use them to gain access to servers.

11. 11
TICKETS (CONT.)
• The TGS seals (encrypts) each ticket with the secret
encryption key of the server.
• Sealed tickets can be sent safely over a network -
only the server can make sense out of it.
• Each ticket has a limited lifetime (a few hours).

12. 12
TICKET CONTENTS
• Client name (user login name)
• Server name
• Client Host network address
• Session Key for Client/Server
• Ticket lifetime
• Creation timestamp

13. 13
SESSION KEY
• Random number that is specific to a session.
• Session Key is used to seal client requests to server.
• Session Key can be used to seal responses
(application specific usage).

14. 14
AUTHENTICATORS
• Authenticators prove a client’s identity.
• Includes:
– Client user name.
– Client network address.
– Timestamp.
• Authenticators are sealed with a session key.

15. 15
BOOTSTRAP
• Each time a client wants to contact a server, it must
first ask the 3rd party (TGS) for a ticket and session
key.
• In order to request a ticket from the TGS, the client
must already have a TG ticket and a session key for
communicating with the TGS!

16. 16
AUTHENTICATION SERVER
• The client sends a plaintext request to the AS
asking for a ticket it can use to talk to the TGS.
• REQUEST:
– login name
– TGS name
Since this request contains only well-known names,
it does not need to be sealed.

17. 17
AUTHENTICATION SERVER
• The AS finds the keys corresponding to the
login name and the TGS name.
• The AS creates a ticket:
– login name
–TGS name
– client network address
–TGS session key
• The AS seals the ticket with the TGS secret
key.

18. 18
AUTHENTICATION SERVER RESPONSE
• The AS also creates a random session key for the
client and the TGS to use.
• The session key and the sealed ticket are sealed
with the user (login name) secret key.
TGS session key
Ticket:
login name
TGS name
net address
TGS session key
Sealed with user key
Sealed with TGS key

19. 19
ACCESSING THE TGS
• The client decrypts the message using the user’s
password as the secret key.
• The client now has a session key and ticket that can
be used to contact the TGS.
• The client cannot see inside the ticket, since the
client does not know the TGS secret key.

20. 20
• When a client wants to start using a server
(service), the client must first obtain a
ticket.
• The client composes a request to send to
the TGS:
ACCESSING A SERVER
TGS Ticket
Authenticator
Server Name
sealed with
TGS key
sealed with
session key

21. 21
TGS RESPONSE
• The TGS decrypts the ticket using it’s secret
key. Inside is the TGS session key.
• The TGS decrypts the Authenticator using the
session key.
• The TGS check to make sure login names,
client addresses and TGS server name are all
OK.
• TGS makes sure the Authenticator is recent.

22. 22
TGS Response
Once everything checks out - the TGS:
• builds a ticket for the client and requested server.
The ticket is sealed with the server key.
• creates a session key
• seals the entire message with the TGS session key
and sends it to the client.

23. 23
CLIENT ACCESSES SERVER
• The client now decrypts the TGS response using the
TGS session key.
• The client now has a session key for use with the
new server, and a ticket to use with that server.
• The client can contact the new server using the same
format used to access the TGS.

24. Kerberos versions
• trusted key server system from MIT
• provides centralised private-key third-party
authentication in a distributed network
– allows users access to services distributed through
network
– without needing to trust all workstations
– rather all trust a central authentication server
• two versions in use: 4 & 5

25. KERBEROS REQUIREMENTS
• first published report identified its requirements as:
– security
– reliability
– transparency
– scalability
• implemented using an authentication protocol based
on Needham-Schroeder

26. KERBEROS 4 OVERVIEW
• a basic third-party authentication scheme
• have an Authentication Server (AS)
– users initially negotiate with AS to identify self
– AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)
• have a Ticket Granting server (TGS)
– users subsequently request access to other
services from TGS on basis of users TGT

27. KERBEROS 4 OVERVIEW

28. KERBEROS REALMS
• a Kerberos environment consists of:
– a Kerberos server
– a number of clients, all registered with server
– application servers, sharing keys with server
• this is termed a realm
– typically a single administrative domain
• if have multiple realms, their Kerberos servers
must share keys and trust

29. KERBEROS VERSION 5
• developed in mid 1990’s
• provides improvements over v4
– addresses environmental shortcomings
• encryption alg, network protocol, byte order, ticket
lifetime, authentication forwarding, interrealm auth
– and technical deficiencies
• double encryption, non-std mode of use, session keys,
password attacks
• specified as Internet standard RFC 1510

30. 30
KERBEROS SUMMARY (CONT.)
• Tickets have a finite lifetime.
• Authenticators are only used once (new
connection to a server).
• Authenticators expire fast !
• Server maintains list of authenticators
(prevent stolen authenticators).
• There is a lot more to Kerberos!!!

31. X.509 Authentication Service
• part of CCITT X.500 directory service standards
– distributed servers maintaining user info database
• defines framework for authentication services
– directory may store public-key certificates
– with public key of user signed by certification authority
• also defines authentication protocols
• uses public-key crypto & digital signatures
– algorithms not standardised, but RSA recommended
• X.509 certificates are widely used

32. X.509 CERTIFICATES
• issued by a Certification Authority (CA), containing:
– version (1, 2, or 3)
– serial number (unique within CA) identifying
certificate
– signature algorithm identifier
– issuer X.500 name (CA)
– period of validity (from - to dates)
– subject X.500 name (name of owner)
– subject public-key info (algorithm, parameters, key)
– issuer unique identifier (v2+)
– subject unique identifier (v2+)
– extension fields (v3)
– signature (of hash of all fields in certificate)
• notation CA<<A>> denotes certificate for A signed by CA

33. X.509 CERTIFICATES

34. OBTAINING A CERTIFICATE
• any user with access to CA can get any certificate
from it
• only the CA can modify a certificate
• because cannot be forged, certificates can be placed
in a public directory

35. CA HIERARCHY
• if both users share a common CA then they are
assumed to know its public key
• otherwise CA's must form a hierarchy
• use certificates linking members of hierarchy to
validate other CA's
– each CA has certificates for clients (forward) and
parent (backward)
• each client trusts parents certificates
• enable verification of any certificate from one CA by
users of all other CAs in hierarchy

36. CA HIERARCHY USE

37. CERTIFICATE REVOCATION
• certificates have a period of validity
• may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
• CA’s maintain list of revoked certificates
– the Certificate Revocation List (CRL)
• users should check certificates with CA’s CRL

38. AUTHENTICATION PROCEDURES
• X.509 includes three alternative authentication
procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures

39. One-Way Authentication
• 1 message ( A->B) used to establish
– the identity of A and that message is from A
– message was intended for B
– integrity & originality of message
• message must include timestamp, nonce, B's
identity and is signed by A
• may include additional info for B
– eg session key

40. Two-Way Authentication
• 2 messages (A->B, B->A) which also
establishes in addition:
– the identity of B and that reply is from B
– that reply is intended for A
– integrity & originality of reply
• reply includes original nonce from A, also
timestamp and nonce from B
• may include additional info for A

41. THREE-WAY AUTHENTICATION
• 3 messages (A->B, B->A, A->B) which enables above
authentication without synchronized clocks
• has reply from A back to B containing signed copy of
nonce from B
• means that timestamps need not be checked or
relied upon

42. X.509 VERSION 3
• has been recognised that additional information is
needed in a certificate
– email/URL, policy details, usage constraints
• rather than explicitly naming new fields defined a
general extension method
• extensions consist of:
– extension identifier
– criticality indicator
– extension value

43. Certificate Extensions
• key and policy information
– convey info about subject & issuer keys, plus
indicators of certificate policy
• certificate subject and issuer attributes
– support alternative names, in alternative formats
for certificate subject and/or issuer
• certificate path constraints
– allow constraints on use of certificates by other
CA’s

44. 44
EMAIL SECURITY
• email is one of the most widely used and regarded
network services
• currently message contents are not secure
– may be inspected either in transit
– or by suitably privileged users on destination
system

45. 45
EMAIL SECURITY ENHANCEMENTS
• Confidentiality
– Protection from disclosure
• Authentication
– Of sender of message
• Message integrity
– Protection from modification
• Non-repudiation of origin
– Protection from denial by sender

46. S/MIME
• What is S/MIME?
• Why do we care about it?
• Secrecy, authentication, and integrity
• Cryptography primer, including public key techniques
and certificates
• How S/MIME works
• Where S/MIME is used in Notes/Domino
• How to use S/MIME

47. AUDIENCE
• Experienced with Notes, Domino, general email
topics
• Used some encryption/privacy tools
• Not a security expert or mathematician (will skip
gory details)
• My goal is to explain a fairly complex topic to a
generally knowledgeable computer audience

48. WHAT IS S/MIME?
• When email was first developed, people could only
send plain text messages
• MIME was developed in early 90s to allow people to
send pictures, sound, programs and general
attachments -- “Multipurpose Internet Mail
Extension”
• MIME has no security features, can be read along its
route or forged (easily)
• S/MIME is a secure version of MIME

49. WHAT DOES S/MIME GIVE US?
• Secrecy – Only intended recipient can read the
message. (A thick envelope and trustworthy
couriers.)
• Authentication – Recipient knows the message came
from the apparent sender. (An ink signature that you
recognize.)
• Integrity – Recipient knows the message was not
changed en route. (Un-erasable ink in a letter.)

50. CRYPTOGRAPHY PRIMER
• Secret key (a.k.a symmetric cipher)
• Public key (a.k.a. asymmetric cipher)
– Secrecy
– Authentication
– Secrecy and authentication
• Hashing (a.k.a. message digest)
• Public key certificate (X.509)

51. SYMMETRIC CIPHER
• Dates back thousands of years
• A “key” is scrambled into the message in a way that
makes the message unreadable
• Scrambling method can be pencil and paper,
mechanical, or mathematical
• Key can be numbers, letters, text from a book
• Only way to read the message (easily) is to
unscramble it with the same key
• Sender and receiver must exchange key somehow

52. SYMMETRIC CIPHER

53. PUBLIC KEY CRYPTOGRAPHY (PKC)
• Invented in 1970s
• There are two keys; one public for all to see, the
other kept secret to one person
• Keys are pairs of large numbers, related to prime
number theory
• Message is scrambled with one key; only
unscrambled easily with the other key
• Can be used for secrecy, authentication, or both

54. PUBLIC KEY CRYPTOGRAPHY

55. PKC FOR SECRECY ONLY
• Chuck wants to send message that only Katie can
read
• Ciphertext = PKC(plaintext, katie’s public key)
• Plaintext = PKC(ciphertext, katie’s private key)
• Only Katie can decrypt the message, and Chuck does
not have to send her a key

56. PKC FOR AUTHENTICATION ONLY
• Chuck wants to send message to Katie and prove it is
from him
• Ciphertext = PKC(plaintext1, chuck’s private key)
• Chuck sends ciphertext and plaintext1
• Plaintext2 = PKC(ciphertext, chuck’s public key)
• Katie compares plaintext1 (sent) with plaintext2
(decrypted)
• If they match, only Chuck could have sent the
message.

57. PKC FOR SECRECY AND AUTHENTICATION
• Chuck wants to send secret message to Katie and
prove it is from him
• Cipher1 = PKC(plaintext1, chuck’s private key)
• Cipher2 = PKC(Cipher1 and plaintext1, katie’s public
key)
• Chuck sends Cipher2
• Cipher1 and Plaintext1 = PKC(Cipher2, katie’s private
key)
• Plaintext2 = PKC(Cipher1, chuck’s public key)
• Katie compares plaintext1 (sent) with plaintext2
(decrypted)

58. HASHING
• A one-way operation that is hard to undo
• Often results in a shorter message, which is called a
message digest
• Example: “Let’s have breakfast at Dunkin Donuts” 
“h7tfd8Fr”

59. PUBLIC KEY CERTIFICATE
• But, there is a problem with PKC… How does Katie
know it is really Chuck sending her the message.
Someone could pretend to be Chuck.
• Public key certificates solve this problem (mostly)
• A public key certificate contains
– A person’s name
– That person’s public key
– Name of a trusted certifying authority (CA)
– Digital signature of the CA, using their private key
• Certificate can be verified with CA’s public key
• X.509 is most common format

60. SO WHAT IS S/MIME?
• S/MIME puts all these techniques together to create
a practical, efficient, reasonably secure email
protocol
• Standard (symmetric) cipher – RC2 or TripleDES
• Public key (asymmetric) cipher – RSA
• Hashing – SHA-1 or MD5
• (Mathematical details found in references)

61. S/MIME FOR SECRECY ONLY
1. Chuck’s email program creates a random key
(session key) to be used in a symmetric cipher.
2. Chuck’s email program encrypts the message with
the symmetric cipher and session key.
3. Chuck’s email program encrypts the session key
with PKC and Katie's public key.
4. Chuck’s email program creates a package of:
encrypted message, encrypted session key, his
X.509 certificate, names of encryption algorithms.

62. S/MIME FOR SECRECY, CONTINUED
5. Chuck’s email program sends package to Katie. This
is an S/MIME email message.
6. Katie’s email program receives package.
7. Katie's email program uses her private key (and
named PKC method) to decrypt the session key.
8. Katie’s email program uses session key (and named
symmetric cipher) to decrypt the message.

63. S/MIME FOR AUTHENTICATION ONLY
1. Chuck’s email program uses hash function to create
message digest
2. Chuck’s email program encrypts message digest
with PKC and his private key
3. Chuck’s email program creates a package of:
original message, encrypted message digest, his
X.509 certificate, names of encryption algorithms
4. Chuck’s email program sends package to Katie.
5. Katie's email program receives package

64. S/MIME FOR AUTHENTICATION,
CONTINUED
6. Katie’s email program verifies Chuck’s X.509
certificate by testing signature of CA
7. Katie’s email program gets Chuck’s public key from
his certificate
8. Katie's email program uses Chuck’s public key to
decrypt the message digest
9. Katie's email program independently computes the
message digest, using the same hash function
10. Katie's email program compares the two message
digests to verify sender and message integrity

65. S/MIME FOR SECRECY AND
AUTHENTICATION
1. Message is authenticated just as shown above
2. Authenticated package is made secret, just as
shown above
3. Secret package is sent to recipient
4. Receiver uses his/her private key to decrypt session
key
5. Receiver uses session key to decrypt rest of secret
package, yielding authenticated message
6. Receiver authenticates message, just as shown
above

66. SO S/MIME IS USED FOR NOTES MAIL?
• No! For pure Notes email (Notes and Domino)
S/MIME is not needed. Notes has its own, similar,
methods.
• S/MIME is used whenever pure Notes email is not
available
– From Notes, through Domino, to other email
– From Notes, through standard server, to any email
– From other email, through Domino, to any email

67. USING S/MIME
• Get a digital identification
• Set up Domino server for S/MIME
• Use S/MIME with general email clients
• Use S/MIME with Notes

68. Getting a digital identification
• A digital ID is
– Your name
– Public/private key pair
– Public key certificate for this ID
• Most popular vendors are www.Thawte.com
and www.VeriSign.com
• Thawte is free, but VeriSign is only $15/year
and simpler to use

69. SETTING UP DOMINO FOR S/MIME
• Do nothing! (other than standard Internet mail set
up)
• (If anyone is aware of special settings that are
required, please let me know.)

70. S/MIME WITH STANDARD EMAIL
CLIENTS (E.G. OUTLOOK EXPRESS)
• If you got your digital ID on this computer, it is
already installed
(Can see the ID with Start / Settings / Control Panel /
Internet Options / Content / Certificates)
• For secrecy, just press Encrypt
• For authentication, just press Sign
• When receiving a message, you will see security
symbols near the attachment paperclip

71. USING S/MIME WITH NOTES
(Assuming digital ID already on Windows computer)
1. Export digital ID from Windows
2. Import digital ID to Notes ID file
3. Make sure this certificate will be used for Internet
mail from Notes
4. Use digital ID as you send and receive email

72. 72
PRETTY GOOD PRIVACY (PGP)
• Open source, freely available software package for
secure e-mail
• de facto standard for secure email
• developed by Phil Zimmermann
• selected best available crypto algs to use
• Runs on a variety of platforms like Unix, PC,
Macintosh and other systems
• originally free (now also have commercial versions
available)

73. 73
PGP OPERATION – AUTHENTICATION
1. sender creates message
2. Generates a digital signature for the message
3. use SHA-1 to generate 160-bit hash of message
4. signed hash with RSA using sender's private key, and
is attached to message
5. receiver uses RSA with sender's public key to
decrypt and recover hash code
6. receiver verifies received message using hash of it
and compares with decrypted hash code

74. 74
PGP OPERATION – CONFIDENTIALITY
1. sender generates a message and encrypts it.
2. Generates a128-bit random number as session key
3. Encrypts the message using CAST-128 / IDEA / 3DES
in CBC mode with session key
4. session key encrypted using RSA with recipient's
public key and attached to the msg
5. receiver uses RSA with private key to decrypt and
recover session key
6. session key is used to decrypt message

75. 75
PGP OPERATION – CONFIDENTIALITY &
AUTHENTICATION
• can use both services on the same message
– create signature & attach it to the message
– encrypt both message & signature
– attach RSA/ElGamal encrypted session key
This sequence is preferred because
--one can store the plaintext message/file and its
signature
--no need to decrypt the message/file again and
again

76. 76
PGP OPERATION – COMPRESSION
• PGP compresses messages to save space for e-mail
transmission and storage
• by default PGP compresses message after signing but
before encrypting
– so can store uncompressed message & signature
for later verification
– Encryption after compression strengthens security
(because compression has less redundancy)
• uses ZIP compression algorithm

77. 77
PGP OPERATION – EMAIL COMPATIBILITY
• when using PGP will have binary data (8-bit octets) to
send (encrypted message, etc)
• however email was designed only for text
• hence PGP must encode raw binary data into
printable ASCII characters
• uses radix-64 algorithm
– maps 3 bytes to 4 printable chars
– also appends a CRC
• PGP also segments messages if too big
(maximum length 50,000 octets)

78. 78
PGP OPERATION – SUMMARY

79. 79
PGP SESSION KEYS
• need a session key for each message
– of varying sizes: 56-bit DES, 128-bit CAST or IDEA,
168-bit Triple-DES
• uses random inputs taken from
-actual keys hit
-keystroke timing of a user

80. 80
PGP PUBLIC & PRIVATE KEYS
• since many public/private keys may be in use, need
to identify which is actually used to encrypt session
key in a message
– could send full public-key with every message
– but this is inefficient
• rather use a key identifier based on key
– is least significant 64-bits of the key
– will very likely be unique
• also use key ID in signatures

81. 81
PGP MESSAGE FORMAT

82. 82
PGP KEY RINGS
• each PGP user has a pair of keyrings:
– public-key ring contains all the public-keys of
other PGP users known to this user, indexed by
key ID
– private-key ring contains the public/private key
pair(s) for this user, indexed by key ID & encrypted
keyed from a hashed passphrase
• security of private keys thus depends on the pass-
phrase security

83. 83
PGP MESSAGE GENERATION

84. 84
PGP MESSAGE RECEPTION

85. IP SECURITY: THE NEED...
• In CERTs 2001 annual report it listed 52,000
security incidents
• the most serious involving:
– IP spoofing
• intruders creating packets with false address
then taking advantages of OS exploits
– eavesdropping and sniffing
• attackers listen for userids and passwords
and then just walk into target systems
– as a result the IAB included authentication and
encryption in the next generation IP (IPv6)

86. IP SECURITY
• We’ve considered some application specific security
mechanisms
– eg. S/MIME, PGP, Kerberos, SSL/HTTPS
• however there are security concerns that cut across
protocol layers
• would like security implemented by the network for
all applications

87. IPSEC
• general IP Security mechanisms
• provides
– authentication
– confidentiality
– key management
• applicable to use over LANs, across public &
private WANs, & for the Internet

88. IPSEC USES

89. BENEFITS OF IPSEC
• in a firewall/router provides strong security to all traffic
crossing the perimeter
• is resistant to bypass
• is below transport layer, hence transparent to applications
• can be transparent to end users
• can provide security for individual users if desired
• additionally in routing applications:
– assure that router advertisments come from authorized
routers
– neighbor advertisments come from authorized routers
– insure redirect messages come from the router to which
initial packet was sent
– insure no forging of router updates

90. IP SECURITY ARCHITECTURE
• RFC 2401 (Primary RFC)
• specification is quite complex
• defined in numerous RFC’s
– incl. RFC 2401/2402/2406/2408
– many others, grouped by category
• mandatory in IPv6, optional in IPv4

91. IPSEC SERVICES
• Two protocols are used to provide security:
– Authentication Header Protocol (AH)
– Encapsulation Security Payload (ESP)
• Services provided are:
– Access control
– Connectionless integrity
– Data origin authentication
– Rejection of replayed packets
• a form of partial sequence integrity
– Confidentiality (encryption)
– Limited traffic flow confidentiality

92. SECURITY ASSOCIATIONS
• a one-way relationship between sender & receiver
that affords security for traffic flow
• defined by 3 parameters:
– Security Parameters Index (SPI)
• a bit string
– IP Destination Address
• only unicast allowed
• could be end user, firewall, router
– Security Protocol Identifier
• indicates if SA is AH or ESP
• has a number of other parameters
– seq no, AH & EH info, lifetime etc
• have a database of Security Associations

93. AUTHENTICATION HEADER (AH)
• RFC 2402
• provides support for data integrity &
authentication of IP packets
– end system/router can authenticate user/app
– prevents address spoofing attacks by tracking
sequence numbers

94. • based on use of a MAC (message authentication
code)
– HMAC-MD5-96 or HMAC-SHA-1-96
– MAC is calculated:
• immutable IP header fields
• AH header (except for Authentication Data
field)
• the entire upper-level protocol data
(immutable)
• parties must share a secret key

95. AUTHENTICATION HEADER

96. TRANSPORT AND TUNNEL MODES
• Both AH and ESP have two modes
– transport mode is used to encrypt & optionally
authenticate IP data
• data protected but header left in clear
• can do traffic analysis but is efficient
• good for ESP host to host traffic
– tunnel mode encrypts entire IP packet
• add new header for next hop
• good for VPNs, gateway to gateway security

97. TRANSPORT & TUNNEL MODES

98. ENCAPSULATING SECURITY PAYLOAD (ESP)
• RFC 2406
• provides message content confidentiality &
limited traffic flow confidentiality
• can optionally provide the same authentication
services as AH
• supports range of ciphers, modes, padding
– incl. DES, Triple-DES, RC5, IDEA, CAST etc
– CBC most common
– pad to meet blocksize, for traffic flow

99. ENCAPSULATING SECURITY PAYLOAD

100. COMBINING SECURITY ASSOCIATIONS
• SA’s can implement either AH or ESP
• to implement both need to combine SA’s
– form a security bundle
• have 4 cases (see next)

101. COMBINING SECURITY ASSOCIATIONS
a. AH in transport mode
b.ESP in transport mode
c. AH followed by ESP in transport mode(ESP SA inside an AH SA
d. any one a, b, c inside an AH or ESP in tunnel mode

102. KEY MANAGEMENT
• handles key generation & distribution
• typically need 2 pairs of keys
– 2 per direction for AH & ESP
• manual key management
– sysadmin manually configures every system
• automated key management
– automated system for on demand creation of keys
for SA’s in large systems
– has Oakley & ISAKMP elements

103. OAKLEY
• RFC 2412
• a key exchange protocol
• based on Diffie-Hellman key exchange
• adds features to address weaknesses
– cookies, groups (global params), nonces, DH key
exchange with authentication
• can use arithmetic in prime fields or elliptic curve fields

104. ISAKMP
• Internet Security Association and Key Management
Protocol (RFC 2407)
• provides framework for key management
• defines procedures and packet formats to establish,
negotiate, modify and delete SAs
• independent of key exchange protocol, encryption
algorithm and authentication method

105. ISAKMP

106. SUMMARY
• have considered:
– IPSec security framework
– AH Protocol
– ESP Protocol
– key management & Oakley/ISAKMP

107. WEB SECURITY
• Web now widely used by business, government,
individuals
• but Internet & Web are vulnerable
• have a variety of threats
– integrity
– confidentiality
– denial of service
– authentication
• need added security mechanisms

108. SSL (SECURE SOCKET LAYER)
• transport layer security service
• originally developed by Netscape
• version 3 designed with public input
• subsequently became Internet standard known as
TLS (Transport Layer Security)
• uses TCP to provide a reliable end-to-end service
• SSL has two layers of protocols

109. SSL ARCHITECTURE

110. SSL ARCHITECTURE
• SSL session
– an association between client & server
– created by the Handshake Protocol
– define a set of cryptographic parameters
– may be shared by multiple SSL connections
• SSL connection
– a transient, peer-to-peer, communications link
– associated with 1 SSL session

111. SSL RECORD PROTOCOL
• confidentiality
– using symmetric encryption with a shared secret
key defined by Handshake Protocol
– IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-
40, RC4-128
– message is compressed before encryption
• message integrity
– using a MAC with shared secret key
– similar to HMAC but with different padding

112. SSL Change Cipher Spec Protocol
• one of 3 SSL specific protocols which use the
SSL Record protocol
• a single message
• causes pending state to become current
• hence updating the cipher suite in use

113. SSL ALERT PROTOCOL
• conveys SSL-related alerts to peer entity
• severity
• warning or fatal
• specific alert
• unexpected message, bad record mac,
decompression failure, handshake failure,
illegal parameter
• close notify, no certificate, bad certificate,
unsupported certificate, certificate revoked,
certificate expired, certificate unknown
• compressed & encrypted like all SSL data

114. SSL HANDSHAKE PROTOCOL
• allows server & client to:
– authenticate each other
– to negotiate encryption & MAC algorithms
– to negotiate cryptographic keys to be used
• comprises a series of messages in phases
– Establish Security Capabilities
– Server Authentication and Key Exchange
– Client Authentication and Key Exchange
– Finish

115. SSL HANDSHAKE PROTOCOL

116. TLS (TRANSPORT LAYER SECURITY)
• IETF standard RFC 2246 similar to SSLv3
• with minor differences
– in record format version number
– uses HMAC for MAC
– a pseudo-random function expands secrets
– has additional alert codes
– some changes in supported ciphers
– changes in certificate negotiations
– changes in use of padding

117. SECURE ELECTRONIC TRANSACTIONS
(SET)
• open encryption & security specification
• to protect Internet credit card transactions
• developed in 1996 by Mastercard, Visa etc
• not a payment system
• rather a set of security protocols & formats
– secure communications amongst parties
– trust from use of X.509v3 certificates
– privacy by restricted info to those who need it

118. SET COMPONENTS

119. SET TRANSACTION
1. customer opens account
2. customer receives a certificate
3. merchants have their own certificates
4. customer places an order
5. merchant is verified
6. order and payment are sent
7. merchant requests payment authorization
8. merchant confirms order
9. merchant provides goods or service
10. merchant requests payment

120. DUAL SIGNATURE
• customer creates dual messages
– order information (OI) for merchant
– payment information (PI) for bank
• neither party needs details of other
• but must know they are linked
• use a dual signature for this
– signed concatenated hashes of OI & PI

121. PURCHASE REQUEST – CUSTOMER

122. PURCHASE REQUEST – MERCHANT

123. PURCHASE REQUEST – MERCHANT
1. verifies cardholder certificates using CA sigs
2. verifies dual signature using customer's public
signature key to ensure order has not been
tampered with in transit & that it was signed using
cardholder's private signature key
3. processes order and forwards the payment
information to the payment gateway for
authorization (described later)
4. sends a purchase response to cardholder

124. PAYMENT GATEWAY AUTHORIZATION
1. verifies all certificates
2. decrypts digital envelope of authorization block to
obtain symmetric key & then decrypts authorization
block
3. verifies merchant's signature on authorization block
4. decrypts digital envelope of payment block to obtain
symmetric key & then decrypts payment block
5. verifies dual signature on payment block
6. verifies that transaction ID received from merchant
matches that in PI received (indirectly) from customer
7. requests & receives an authorization from issuer
8. sends authorization response back to merchant

125. PAYMENT CAPTURE
• merchant sends payment gateway a payment
capture request
• gateway checks request
• then causes funds to be transferred to merchants
account
• notifies merchant using capture response

126. SUMMARY
• have considered:
– need for web security
– SSL/TLS transport layer security protocols
– SET secure credit card payment protocols