IC3 - Network Security
M.Sc. in Information Security
Royal Holloway, University of London
1
IC3 - Network Security
Lecture 4
Introduction to Secure Protocols
2
Objectives of Lecture
CINS/F1-01
• Define what a secure protocol is.
• Model the principals involved in secure protocols, and
their capabilities.
• Demonstrate how basic cryptographic mechanisms can
be used to build entity authentication and key
distribution protocols suited to insecure networks.
• Appreciate how key distribution and entity
authentication can be enabled using trusted third
parties.
• Describe the main features of the Kerberos protocol
suite and outline its application in Windows 2000.
3
Contents
4.1
4.2
4.3
4.4
Secure protocols
Entity Authentication and Key Agreement
Key Distribution via Trusted Third Parties
Kerberos
4
4.1 Secure Protocols
• A protocol is a set of rules for exchanging
messages between 2 (or more) principals over
a network.
• The word ‘protocol’ in the OSI model is
reserved and refers to rules governing
communication between a pair of peer entities.
• We’ll use it here in a more general way.
• In this lecture, we largely leave unspecified the
OSI layer at which our protocols operate.
– Lectures 5 and 6 will look at protocols for specific
layers.
5
Secure Protocols
So what is a secure protocol?
• When acting honestly, principals (participants)
achieve the stated aim of the protocol (e.g. A
successfully authenticates to B, or A and B
exchange a fresh session key).
• Neither passive eavesdropper nor malicious,
active adversary can defeat this objective (e.g.
by successfully impersonating A in an
authentication protocol with B).
6
The Principals – 1
• Alice and Bob who wish to authenticate one
another or to share a key.
• In more complex protocols, Trent, a trusted
third party who is trusted by both Alice and Bob
– aka (depending on application) TTP, key distribution
centre (KDC), certification authority (CA),….
– What Trent is trusted to do (and not do) depends on
the protocol and application.
7
The Principals – 2
Two kinds of adversary:
• Eve, a passive eavesdropper (‘sniffs’ messages at will).
• Mallory, an active adversary, who can view, alter,
delete, replay and inject messages into the network,
initiate protocol ‘runs’, take on the role of any principal
in any protcol ‘run’, ….
Warning 1: ‘Alice’, ‘Bob’, etc are only semantic sugar:
most protocols on networks don’t involve real people.
Warning 2: We’ll freely mix up A for Alice and B for
Bob, etc.
8
The Principals – 3
Mallory is not all-powerful:
• He cannot guess a random number chosen by
another principal from a sufficiently large space.
• He cannot invert a one-way hash function.
• Without the correct key, he cannot obtain the
plaintext for a given ciphertext. Nor can he compose
ciphertexts for plaintexts of his choice.
• He cannot sign messages without having the
appropriate private key.
• He cannot correctly compute a MAC on a message
without knowing the correct secret key.
• In summary: Mallory cannot break strong
cryptographic mechanisms.
9
Summary So Far
• So we equip Alice, Bob, Trent with strong
cryptographic mechanisms to use on a
completely untrusted network.
• The question then is:
How do we use these cryptographic
mechanisms (signatures, public-key and
symmetric key encryption, hash functions,
MACs) to design secure protocols (providing
security services)?
10
4.2 Entity Authentication
• The OSI security architecture (ISO 7498-2)
distinguishes between origin authentication
(verifying origin of received data) and entity
authentication (identity verification).
• An origin authentication service can be built
from a MAC.
• Here we consider entity authentication, a basic
security service in networks (Lecture 1).
• Typically achieved by exchange of
cryptographic messages called an
authentication protocol (authentication
exchange in ISO 7498-2).
11
Definitions
• Entity authentication:
– the corroboration that an entity is the one claimed at
a particular point in time (no guarantees after that
time).
• Unilateral authentication:
– entity authentication which provides one entity with
assurance of the other’s identity but not vice versa.
• Mutual authentication:
– entity authentication which provides both entities
with assurance of each other’s identity.
12
Basis for Authentication
•
Suppose we want to design a protocol which
authenticates Alice to Bob. Is the following secure?
A
B:
‘Hi Bob, I’m Alice’
• No: Mallory can easily impersonate Alice in this protocol.
• So we need something stronger.
• Authentication protocols can be built from the assumption
that Alice and Bob share a key, or that Alice and Bob have
authentic copies of each others’ public keys.
13
Strong Authentication
• In strong authentication, one entity ‘proves’ its identity
to another by demonstrating knowledge of a secret
known to be associated with that entity, without
revealing that secret itself during the protocol.
• Also called ‘challenge-response’ authentication.
• Use cryptographic mechanisms to protect messages in
protocol:
– Encryption.
– Integrity mechanism (e.g. MAC).
– Digital signature.
14
Example: Passwords
• Suppose Alice sends a password matching her
user ID over the network, Bob compares to
entry in password file.
• Is this a strong authentication protocol?
– Password transmitted in clear over network, so may
be sniffable by Mallory – hence weak authentication.
– Not suitable for use over open networks.
– For a degree of added security, transmit only
hashed passwords – still vulnerable to dictionary
attack (hash an entire dictionary word by word and
compare to hashed password).
15
Encryption-based Unilateral
Authentication
• Assume Alice (client) and Bob (server) share a secret
key K.
• Design goal: Bob to authenticate Alice.
• Alice sends an initiating message.
• Bob sends Alice a challenge message R.
• Alice responds with {R || B}K, message R concatenated
with B, encrypted using shared key K.
• Bob checks that the message he received decrypts to
give message R || B.
• If it does, then Alice is authenticated to Bob (or Bob
authenticates Alice).
16
The Protocol
1. A
2. B
3. A
B:
A:
B:
‘Hi Bob, I’m Alice’
R
(challenge)
{R || B}K
(response)
(Here, {X}K means string X encrypted under
key K, and || means concatenation of
strings.)
17
Security of the Protocol – 1
1. Why can Bob be sure that message 3 in the
protocol came from Alice?
2. Why can Bob be sure that message 3 in the
protocol is not a replay of a message from an
earlier run of the protocol between himself
and Alice?
1. Only Alice (and Bob) know secret key K.
2. Bob chose R at random just before sending
message 2. This R is fresh: it has never been
used before. This means that message 3,
which includes R in encrypted form, has never
been produced before.
18
Security of the Protocol – 2
1. Why can Bob be sure that message 3 in the
protocol is intended for him?
2. Can an attacker learn the value of secret key
K by observing multiple runs of the protocol?
1. Alice includes Bob identity ‘B’ in the encrypted
message. This prevents Mallory taking a
message intended for Alice and sending it to
Bob.
2. No, not if the encryption algorithm is strong.
19
Security of the Protocol – 3
1. Is Alice authenticated to Bob in this protocol?
2. Is Bob authenticated to Alice in this protocol?
3. Is the protocol a mutual authentication or a
unilateral authentication protocol?
1. Yes.
2. No. (In fact Mallory could impersonate Bob in
the protocol, but our design goal was a
protocol in which Alice is authenticated, not
Bob, so this is not a problem.)
3. Unilateral: Alice to Bob.
20
A Replay Attack
•
Suppose Mallory wants to impersonate Alice in this
protocol:
1. M(A) B:
2. B M(A):
3. M(A) B:
•
•
‘Hi Bob, I’m Alice’
R
(challenge)
???
Now Mallory can’t prepare the correct response
{R||B}K to Bob’s challenge because he doesn’t know
the secret key K.
But what if Mallory could predict R? Then we can find
a serious replay attack….
21
A Replay Attack
Mallory starts a protocol run, impersonating
Bob to Alice:
1. A M(B): ‘Hi Bob, I’m Alice’
2. M(B) A: R (M predicts which R will be used later by B)
3. A M(B): {R || B}K
Mallory keeps hold of {R || B}K: it’s going to
come in handy later.
1. M(A) B: ‘Hi Bob, I’m Alice’
2. B
M(A): R (M predicted this R would be used by B)
3. M(A) B: {R || B}K
22
Freshness and Liveness
• The replay attack shows that it is vital that the protocol
contains a means of checking freshness of messages
and liveness of principals.
• Freshness: assurance that message has not been
used previously and originated within an acceptably
recent timeframe.
• Liveness: assurance that message sent by a principal
within an acceptably recent timeframe.
• Two main methods for providing freshness:
– Nonce (Number used once).
– Time-stamps (clock-based or `logical’ time-stamps).
23
Nonces
• Nonce also known as random challenge.
• In our protocol, we depend on B to make sure
R is freshly generated.
• Main property is ‘one-time’ property, so could in
theory use a counter.
• But many protocols need nonces to be
unpredictable to Mallory. Generate at random
from a large set (128 bits, say).
• Notice that in our protocol, R, the nonce is
unpredictable but not secret.
24
Time-stamps – 1
• Inclusion of date/time-stamp in message allows
recipient to check it for freshness (as long as
time-stamp protected by cryptographic means).
• A B: ‘I’m Alice’, {T || B}K
– a single message instead of three.
– Bob decrypts and checks that T is recent and that
his identity is included.
– Only Alice knows K, so only Alice could have
prepared this message. It’s fresh, so Alice is live.
• But now we require securely synchronised
clocks to prevent replay – non-trivial!
25
Time-stamps – 2
• Typical clock drift is 1s per day on work station.
• So need a window of acceptance for Alice’s
messages either side of Bob’s current clock
time (clock drift + variable network propagation
time).
• Also need a log of recently received messages
to prevent Mallory exploiting window with
replay attack.
26
‘Logical’ Time-stamps
• Alternative to clocks: Alice and Bob could use
pair of sequence numbers NAB and NBA in their
communications.
• Every time A sends B a message she includes
value NAB, and increments it. Likewise for B.
• Needs pair of sequence numbers for every pair
of communicating parties.
• Sequence numbers may need to be kept secret
in protocol runs: otherwise they become
predictable to Mallory.
27
Using MACs for Entity Authentication
Replace encryption mechanism with a MAC:
1. A B:
‘Hi Bob, I’m Alice’
2. B A:
R
(challenge)
3. A B:
MACK(R || B)
(response)
Can argue security as for encryption-based
protocol: Only Alice can prepare correct
response for Bob, freshness of R guarantees
liveness of Alice.
What properties of the MAC did we use?
28
Signature-based Entity Authentication
• Instead of challenge/response, now
challenge/signature.
• Use nonces or time-stamps for freshness.
• Rather than a shared secret key, Bob needs to
have authenticated version of Alice’s public key
(and vice-versa for mutual authentication).
29
Signature-based Mutual
Authentication – Example
1. B
2. A
3. B
•
•
•
A:
B:
A:
RB
RA, SA{RA || RB || B}
SB{RB || RA || A}
Here, SA{X} denotes A’s signature on string X.
Protocol achieves mutual authentication (via
two signatures and two nonces).
A and B must of course check the signatures
to ensure their correctness.
30
Using Digital Signatures
• Alice and Bob have to be sure that they are
verifying each other’s signatures.
• Hence need for trust in authenticity of public
keys instead of shared secrets.
• Public keys can be certified by applying the
digital signature of a Trusted Third Party (TTP)
or Certificate Authority (CA).
• Result (public key + entity name + expiry date +
TTP signature on three items) called a
certificate.
31
Using Certificates
• To check a certificate signed by a TTP requires
an authentic copy of the TTP’s public key.
• If two entities have certificates signed by
different TTPs, then a cross-certificate is
needed (i.e. one TTP’s public verification key
signed by the other TTP).
• Leads to notion of certification paths and
public-key infrastructures (PKIs).
• Related protocols are used in SSL and IPSec
(see Lectures 5 and 6).
32
Authenticated Key Establishment – 1
• Entity authentication only achieved for an instant in
time, typically provided at start of a connection/session.
• Mallory could always hijack the connection after that
point.
• What if a secure session is needed?
– A combination of confidentiality, integrity, data origin
authenticity for remainder of communications session.
• Solution: agree session keys as part of the
authentication protocol.
• Then use those session keys in encryption and MAC
mechanisms to build a secure session.
• Bind the session keys to the entity auth. protocol run to
get authenticated key establishment (AKE) protocol.
33
Authenticated Key Establishment – 2
• As a simple example, we can adapt our one message
time-stamp based protocol:
A B: {T || B}K
simply by adding a session key SK in Alice’s message:
A B: {T || B || SK}K
• Alice is authenticated to Bob and they now share
session key SK.
• Because SK is agreed as part of the entity auth.
protocol, it is bound to that protocol run.
• So Bob can be sure that only Alice knows SK.
• Alice can be sure that only Bob could know SK: only
Bob could decrypt the message to extract SK.
34
Authenticated Key Establishment – 3
Public-key encryption can also be used to create
authenticated session keys:
• Alice checks the authenticity of Bob’s public
encryption key PKB using a certificate.
• A B: {SK}PKB
• Bob can obtain the session key SK by
decrypting using his private key.
• Alice and Bob both use SK to derive encryption
and MAC keys to protect their session.
• Alice can be sure that only Bob could know the
session key.
35
Authenticated Key Establishment – 4
• In this protocol, Alice is not authenticated
(anyone can encrypt for Bob).
• B is only implicitly authenticated to A: A is only
assured he’s talking to B if messages in the
subsequent session make sense (i.e. MAC and
decrypt work properly with SK).
• A (much) more complicated version of this
protocol is an option in SSL (see Lecture 6).
36
ISO/IEC 9798
• ISO/IEC 9798, a multi-part standard (currently
five parts published), specifies a variety of
standard authentication protocols (and derived
key establishment protocols).
• Designed to be ‘generic’, i.e. suitable for most
applications.
• ISO/IEC 9798 protocols are robust: designed
by experts who learned from mistakes of earlier
designers.
37
More on Key Agreement
• A session key can be established as a by-product of
an authentication protocol.
• Here we start from the other end, and look at key
agreement protocols, then we consider how to add
authentication.
• The main protocol we study is the Diffie-Hellman Key
Exchange (DHKE) protocol.
• Scenario:
– Alice and Bob don’t already share a key and can’t meet to do
so. How can they make their future communications
confidential?
38
Diffie-Hellman Key Exchange Set-up
• Alice and Bob agree on a large prime p (p has,
say, 1024 bits) and a number g.
• Alice chooses a random x and computes
gx mod p.
• Bob chooses a random y and computes
gy mod p.
39
Diffie-Hellman Key Exchange
1.
2.
3.
4.
A B: gx mod p
B A: gy mod p
A computes (gy)x mod p
B computes (gx)y mod p
But (gx)y = gxy = (gy)x mod p.
So A and B now share a common key gxy !
40
Diffie-Hellman and Eve
• Eve sees only the public values, gx mod p and
gy mod p.
• But to get the key, Eve needs to compute
gxy mod p.
• If p and g are chosen properly, then this is a
hard computational problem.
• Then Diffie-Hellman key exchange protocol will
be secure against Eve, a passive adversary.
41
Diffie-Hellman and Mallory
gx
ga
Mallory
a,b
Alice
x
Bob
gy
y
gb
A,M
K1= (gb)x = (gx)b
M,B
K2= (ga)y = (gy)a
42
The Man-in-the-middle Attack
• Alice thinks she has exchanged key K1 with
Bob.
– Instead, it’s with Mallory.
• Bob thinks he has exchanged key K2 with Alice.
– Instead, it’s with Mallory.
• Mallory can now
–
–
–
–
–
intercept all messages from A intended for to B,
decrypt them using K1,
read them,
re-encrypt them under K2 and
pass them on to B.
• And vice-versa for messages from B to A.
43
What went wrong?
• Simply this: Alice and Bob exchanged a key
without any performing any entity
authentication.
• So keys were exchanged, but Alice and Bob
have no guarantees about with whom their
exchange took place!
• So Diffie-Hellman key exchange protocol is not
secure against Mallory, an active adversary.
44
Station-to-Station Protocol
The station-to-station protocol adds
authentication (via signatures) to DHKE:
1. A B:
gx
2. B A:
gy, {SB{gy , gx}}K
3. A B:
{SA{gx, gy}}K
•
•
•
•
After step 1, B can compute the shared key K.
After step 2, so can A.
The additional messages are encrypted signatures
on everything fresh in the protocol run; these are
intended to provide authentication and key
confirmation.
These signatures should be checked by A and B.
45
4.3 Key Distribution via TTPs
• Scenario: closed system (security domain) with
n users, potentially n(n-1)/2 keys to allow all
pairs to communicate securely with each other.
• Could use public-key techniques with trust in
keys based on certificates (see SSL example).
• Alternatively, use a trusted third party called a
Key Distribution Centre (KDC) who co-operates
to enable users to authenticate one another
and share session keys.
46
Keys and Trust
• Alice shares a long-term key KA,T with KDC,
Trent.
• Bob also shares a long-term key KB,T with KDC.
• But Alice and Bob do not share a key.
• Alice and Bob use KDC Trent to help them
authenticate one another and agree a session
key K.
• We have a security domain (or realm) formed
by Trent and all the clients:
‘a system under the control of a single
authority which the entities therein trust’
47
Application Scenarios
• A corporate network, with KDC being a server
managed by IT department (say).
• Campus network: authentication controls
access to different services (e-mail, printing,
student records) located on the network
– Now TTP is acting as an authorization server,
granting access to services, rather than as a pure
key distribution centre.
48
Needham-Schroeder Protocol
1.
Trent
(KDC)
2.
3.
4.
1
2
5.
A
T
A
B
A
T: A || B || NA
A: {NA || B || K || {K || A}KB,T}KA,T
B: {K || A}KB,T
A: {NB}K
B: {NB-1}K
3
Alice
4
Bob
5
49
Needham-Schroeder – Step by Step
•
•
In messages 1 and 2, Alice and Trent (the
TTP) interact: Trent gives Alice a session
key K and authenticates himself.
In messages 3,4 and 5, the interaction is
between Alice and Bob. Alice transfers an
encrypted copy of the session key to Bob in
message 3 and is authenticated to Bob in
messages 4 and 5.
50
Security?
• T is authenticated by A and A is implicitly
authenticated by T (recipient can only decrypt
message 2 if he has the correct key KA,T).
• A is authenticated to B (challenge/response).
• If key K is used for subsequent encryption or
MACing, then we get implicit authentication of
B to A (recipient of message 3 can only obtain
K if he knows correct key KB,T).
• Can make A,B authentication mutual by having
A issue a challenge to B along with message 3.
• Session key established: chosen by T, the
KDC.
51
Advantages
• Key storage efficiency: only n keys to look after
at KDC.
• Only one long-term key per client (KA,T) instead
of n-1.
• Only uses symmetric key cryptography.
• Bob can be off-line in steps 1&2 because TTP
doesn’t forward session key K directly to Bob:
Alice relays it to Bob (step 3).
• So K can be cached by Alice and used later.
52
Disadvantages
• KDC is a single point of failure – security and
availability.
• Potential computation/communication
bottleneck at KDC.
• How can we ensure clients look after their longterm keys properly?
– If long-term key compromised, then entities can be
impersonated.
• Requirement for an on-line, trusted server.
– TTP knows all session keys and all long-term keys.
53
4.4 Kerberos
• Kerberos is a TTP-aided authentication
protocol developed from Needham-Schroeder.
• It’s also software implementing that protocol,
currently Kerberos V5 Release 1.3.
– Version 4 (still?) widely used, no longer under
development.
• Also a project at MIT which devised the
protocols (properly called Project Athena).
• Also RFC 1510 – Kerberos V5 (1992).
• A version of Kerberos exists in Windows 2000;
Kerberos is integrated into many versions of
Unix.
54
Kerberos Principals
• Authentication Server (AS) – mutual
authentication with client at login based on
long-term key, gives client ticket granting ticket
and short-term key.
– AS provides an authentication service.
• Ticket Granting Server (TGS) – mutual
authentication with client based on short-term
key and ticket granting ticket. TGS then issues
tickets giving clients access to further servers.
– TGS provides an access control service.
55
Kerberos – Motivations
• Separation of authentication and authorisation/access
control (though AS and TGS usually implemented on
same platform).
• Differentiated control over lifetime of ticket granting
tickets (typically 10 hours) and session tickets for actual
access to services (typically 5 minutes).
• A user only needs to use his long-term secret key once
per 10 hour session, to establish short-term key and
ticket granting ticket.
• Once the short-term key is established (with TGS) the
long-term secret key can be erased from the client
host.
– Minimises risk of exposure of long-term secret key.
56
Kerberos Protocol
AS
TGS
(authentication
server)
(ticketgranting
server)
2
1
C
(client)
3
4
5
S
(server)
6
57
Kerberos Phases
Phase 1: In messages 1 and 2, C and AS
authenticate and set up short-term key and
ticket granting ticket.
Phase 2: In messages 3 and 4, C and TGS
authenticate and set up session keys and
(session) ticket.
Phase 3: In messaged 5 and 6, C and S use
session key and ticket to authenticate and
set up secure session.
Phases 2 and 3 will usually be repeated many
times for each execution of Phase 1.
58
Kerberos – Message Formats
(Simplified)
1. CAS: TGS||from||to||NC
2. ASC: {KC,TGS||C||from||to}KAS,TGS|| {KC,TGS||NC||from||to||TGS}KAS,C
(Note that the first part of message 2 is the Ticket Granting Ticket for
the TGS).
3. CTGS: S||from||to||N’C || {KC,TGS||C||from||to}KAS,TGS || {C||T1}KC,TGS
4. TGSC: {KC,S||C||from||to}KTGS,S || {KC,S|| N’C||from||to||S}KC,TGS
(Note that the first part in message 4 is the Ticket for the server S).
5. CS: {KC,S||C||from||to}KTGS,S || {C||T2}KC,S
6. SC : {T2}KC,S
59
Keys Used in Kerberos
• KAS,TGS is a long-term secret key shared by AS and
TGS.
• KAS,C is a long-term secret key shared by AS and C.
• KTGS,S is a long-term secret key shared by TGS and S.
– These keys need to be established in advance.
• KC,TGS is a secret short-term key shared by C and TGS
(established by messages 1 and 2).
• KC,S is a secret session key shared by C and S
(established by messages 3 and 4).
60
Entity Authentication in Kerberos
• Entity authentications are achieved using a
mixture of nonces and timestamps.
• Methods are similar to ones used in Section 4.2
and in Needham-Schroeder protocol.
• For example: AS is authenticated to C using
challenge/response protocol based on
encryption, shared key KAS,C and nonce NC in
messages 1 and 2.
• Other authentications: C and TGS; C and S.
61
Tickets in Kerberos
• {KC,TGS||C||from||to}KAS,TGS
– Is the ticket granting ticket.
– Received by C in message 2 and sent to TGS in message 3.
– only TGS can decrypt it to obtain short-term key KC,TGS and
validity period from||to. These parameters determine ticket
given to C in message 4.
• {KC,S||C||from||to}KTGS,S
– Is the (session) ticket.
– Received by C in message 4 and sent to S in message 5.
– Only S can decrypt it to obtain session key KC,S and validity
period from||to. These parameters determine access given to C
in subsequent session with server S.
• These tickets are the equivalent of message 3 in
Needham-Schroeder: {K || A}KB,T
62
Use of Cryptography in Kerberos
• Kerberos uses symmetric encryption and
MACs.
• Specifically, Version 5 (as in RFC 1510) uses
DES combined with one of MD4, MD5, or a
CRC (not recommended).
• Releases 1.2 and higher of Kerberos Version 5
allow triple DES (3DES) in CBC-mode.
• Extensions supporting AES and other
algorithms are under development
– AES implemented but not fully enabled in Kerberos
v5 release 1.3.
63
Kerberos Issues – 1
• Revocation: ticket granting tickets valid until
they expire, typically 10 hours. What if
compromised?
• Key management: within realms (domains):
long-term keys need to be established between
AS and TGS, TGS and Servers and AS and
clients.
• Scalability: authentication across realms is
complicated.
• Synchronous clocks needed, protected
against attacks. Caches of recent messages to
protect against replay within clock skew.
64
Kerberos Issues – 2
• Availability: need for on-line AS and TGS,
trusted by clients not to eavesdrop.
• Passwords: Client-AS long-term key usually
based on password entered by user at start of
session – vulnerable to dictionary attacks.
• Key storage: Short-term keys and ticket
granting tickets located on largely unprotected
client hosts.
• Denial of Service: Potential for DoS attacks on
clock service or on AS/TGS?
65
Windows 2000 Network Authentication
• Microsoft have adopted and extended Kerberos
for network authentication in Windows 2000.
• Supersedes Windows NTLM (unilateral
authentication) in NT4.
• One extension:
– support for public-key encryption to protect client/AS
messages (rather than password-based long-term
key).
– allows use of authentication based on client smart
cards.
66
Windows 2000 Network Authentication
• Second extension:
– use of Kerberos data authorization field (normally
empty)
– transports Win2K access privileges
– in the form of SIDs, derived from Active Directory
– these are compared to ACLs of remote objects to
make access decisions.
• Message formats published, but proprietary to
Microsoft.
• Non-standard extension to Kerberos makes it
difficult to interoperate Microsoft and nonMicrosoft implementations.
67
Lessons Learned?
• Designing protocols is easy.
• But designing secure protocols is hard
– there are many infamous failures in the literature.
• Some good protocols are already standardised
(e.g. ISO 9798, ITU-T X.509, …)
– use these rather than rolling your own!
• The problem of verifying security gets harder
as the protocols get more complex.
• Security weaknesses arise from errors in
specification, implementation, side-channels,
lack of user training, host insecurities, poor
random number generation…
68