IC3 - Network Security

1
IC3 - Network Security

• M.Sc. in Information Security
• Royal Holloway, University of London

2
IC3 - Network Security

• Lecture 4
• Introduction to Secure Protocols

3
Objectives of Lecture

• 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.

CINS/F1-01
4
Contents

• 4.1 Secure protocols
• 4.2 Entity Authentication and Key Agreement
• 4.3 Key Distribution via Trusted Third Parties
• 4.4 Kerberos

5
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.
• Well 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.

6
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).

7
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.

8
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 dont involve
  real people.
• Warning 2 Well freely mix up A for Alice and B
  for Bob, etc.

9
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.

10
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)?

11
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).

12
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 others identity but not
  vice versa.
• Mutual authentication
• entity authentication which provides both
  entities with assurance of each others identity.

13
Basis for Authentication

• Suppose we want to design a protocol which
  authenticates Alice to Bob. Is the following
  secure?
• A B Hi Bob, Im 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.

14
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.

15
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).

16
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 BK, 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).

17
The Protocol

• A B Hi Bob, Im Alice
• B A R (challenge)
• A B R BK (response)
• (Here, XK means string X encrypted under
  key K, and means concatenation of strings.)

18
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.

19
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.

20
Security of the Protocol 3

• Is Alice authenticated to Bob in this protocol?
• Is Bob authenticated to Alice in this protocol?
• Is the protocol a mutual authentication or a
  unilateral authentication protocol?

• Yes.
• 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.)
• Unilateral Alice to Bob.

21
A Replay Attack

• Suppose Mallory wants to impersonate Alice in
  this protocol
• M(A) B Hi Bob, Im Alice
• B M(A) R (challenge)
• M(A) B ???
• Now Mallory cant prepare the correct response
  RBK to Bobs challenge because he doesnt
  know the secret key K.
• But what if Mallory could predict R? Then we can
  find a serious replay attack.

22
A Replay Attack
Mallory starts a protocol run, impersonating Bob
to Alice

• A M(B) Hi Bob, Im Alice
• M(B) A R (M predicts which R will be used
  later by B)
• A M(B) R BK

Mallory keeps hold of R BK its going to
come in handy later.

1. M(A) B Hi Bob, Im Alice
2. B M(A) R (M predicted this R would be
   used by B)
3. M(A) B R BK

23
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).

24
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.

25
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 Im Alice, T BK
• 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. Its fresh, so Alice is
  live.
• But now we require securely synchronised clocks
  to prevent replay non-trivial!

26
Time-stamps 2

• Typical clock drift is 1s per day on work
  station.
• So need a window of acceptance for Alices
  messages either side of Bobs 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.

27
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.

28
Using MACs for Entity Authentication

• Replace encryption mechanism with a MAC
• A B Hi Bob, Im Alice
• B A R (challenge)
• 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?

29
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 Alices public key
  (and vice-versa for mutual authentication).

30
Signature-based Mutual Authentication Example

• B A RB
• A B RA, SARA RB B
• B A SBRB RA A
• Here, SAX denotes As 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.

31
Using Digital Signatures

• Alice and Bob have to be sure that they are
  verifying each others 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.

32
Using Certificates

• To check a certificate signed by a TTP requires
  an authentic copy of the TTPs public key.
• If two entities have certificates signed by
  different TTPs, then a cross-certificate is
  needed (i.e. one TTPs 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).

33
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.

34
Authenticated Key Establishment 2

• As a simple example, we can adapt our one message
  time-stamp based protocol
• A B T BK
• simply by adding a session key SK in Alices
  message
• A B T B SKK
• 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.

35
Authenticated Key Establishment 3

• Public-key encryption can also be used to create
• authenticated session keys
• Alice checks the authenticity of Bobs public
  encryption key PKB using a certificate.
• A B SKPKB
• 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.

36
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 hes 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).

37
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.

38
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 dont already share a key and cant
  meet to do so. How can they make their future
  communications confidential?

39
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.

40
Diffie-Hellman Key Exchange

• 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 !

41
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.

42
Diffie-Hellman and Mallory
Alice
Mallory
Bob
gx
ga
x
a,b
y
gy
gb
A,M K1 (gb)x (gx)b
M,B K2 (ga)y (gy)a
43
The Man-in-the-middle Attack

• Alice thinks she has exchanged key K1 with Bob.
• Instead, its with Mallory.
• Bob thinks he has exchanged key K2 with Alice.
• Instead, its 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.

44
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.

45
Station-to-Station Protocol

• The station-to-station protocol adds
• authentication (via signatures) to DHKE
• A B gx
• B A gy, SBgy , gxK
• A B SAgx, gyK
• 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.

46
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.

47
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

48
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.

49
Needham-Schroeder Protocol

• A T A B NA
• T A NA B K K AKB,TKA,T
• A B K AKB,T
• B A NBK
• A B NB-1K

Trent (KDC)
2
1
3
Alice
Bob
4
5
50
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.

51
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.

52
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 12 because TTP
  doesnt forward session key K directly to Bob
  Alice relays it to Bob (step 3).
• So K can be cached by Alice and used later.

53
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
  long-term 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.

54
4.4 Kerberos

• Kerberos is a TTP-aided authentication protocol
  developed from Needham-Schroeder.
• Its 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.

55
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.

56
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.

57
Kerberos Protocol
AS (authentication server)
TGS (ticket- granting server)
2
1
3
4
C (client)
S (server)
5
6
58
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.

59
Kerberos Message Formats (Simplified)

• 1. C?AS TGSfromtoNC
• 2. AS?C KC,TGSCfromtoKAS,TGS
  KC,TGSNCfromtoTGSKAS,C
• (Note that the first part of message 2 is the
  Ticket Granting Ticket for the TGS).
• 3. C?TGS SfromtoNC KC,TGSCfromto
  KAS,TGS CT1KC,TGS
• 4. TGS?C KC,SCfromtoKTGS,S KC,S
  NCfromtoSKC,TGS
• (Note that the first part in message 4 is
  the Ticket for the server S).
• 5. C?S KC,SCfromtoKTGS,S CT2KC,S
  
• 6. S?C T2KC,S

60
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).

61
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.

62
Tickets in Kerberos

• KC,TGSCfromtoKAS,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 fromto. These
  parameters determine ticket given to C in message
  4.
• KC,SCfromtoKTGS,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 fromto. 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 AKB,T

63
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.

64
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.

65
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?

66
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.

67
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
  non-Microsoft implementations.

68
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