Standards

1
Standards

• Kerberos V4

2
Goals of Kerberos

• Kerberos is a network authentication protocol
  created by MIT which uses symmetric key
  cryptography to authenticate users to network
  services eliminating the need to send passwords
  over the network. When users authenticate to
  network services using Kerberos, unauthorized
  users attempting to gather passwords by
  monitoring network traffic are effectively
  thwarted.
• Advantages
• Most conventional network systems use
  password-based authentication schemes. Such
  schemes require a user to authenticate to a given
  network server by supplying their user name and
  password. Unfortunately, the transmission of
  authentication information for many services is
  unencrypted. For such a scheme to be secure, the
  network has to be inaccessible to outsiders, and
  all computers and users on the network must be
  trusted and trustworthy.
• Even if this is the case, once a network is
  connected to the Internet, it can no longer be
  assumed that the network is secure. An attacker
  who gains access can use a simple packet
  analyzer, also known as a packet sniffer, to
  intercept usernames and passwords sent in this
  manner, compromising user accounts and the
  integrity of the entire security infrastructure.
• The primary design goal of Kerberos is to
  eliminate the transmission of unencrypted
  passwords across the network. If used properly,
  Kerberos effectively eliminates the threat packet
  sniffers would otherwise pose on a network.

3
Disadvantages

• Although Kerberos removes a common and severe
  security threat, it may be difficult to implement
  for a variety of reasons
• Migrating user passwords from a standard UNIX
  password database, such as /etc/passwd or
  /etc/shadow, to a Kerberos password database can
  be tedious, as there is no automated mechanism to
  perform this task. For more information, refer to
  question number 2.23 in the Kerberos FAQ online
  at the following URL
• http//www.nrl.navy.mil/CCS/peop
  le/kenh/kerberos-faq.html.
• For an application to use Kerberos, its source
  must be modified to make the appropriate calls
  into the Kerberos libraries. For some
  applications, this can be quite problematic due
  to the size of the application or its design. For
  other incompatible applications, changes must be
  made to the way in which the server and client
  side communicate. Again, this may require
  extensive programming. Closed-source applications
  that do not have Kerberos support by default are
  often the most problematic.
• Kerberos assumes that you are a trusted user
  using an untrusted host on an untrusted network.
  Its primary goal is to prevent plain text
  passwords from being sent across that network.
  However, if anyone other than the proper user has
  access to the one host that issues tickets used
  for authentication called the key distribution
  center (KDC) the entire Kerberos authentication
  system is at risk of being compromised.
• Kerberos is an all or nothing solution. If you
  decide to use Kerberos on your network, you must
  remember that any passwords transferred to a
  service which does not use Kerberos for
  authentication are at risk of being captured by
  packet sniffers. Thus, your network gains no
  benefit from the use of Kerberos. To secure a
  network with Kerberos, one must either use
  kerberized versions of all client/server
  applications which send unencrypted passwords or
  not use any such client/server applications at
  all.

4
Terminology

• ciphertext
• Encrypted data.
• client
• An entity on the network (a user, a host, or an
  application) that can get a ticket from Kerberos.
  
• credential cache or ticket file
• A file which contains the keys for encrypting
  communications between a user and various network
  services. Kerberos 5 supports a framework for
  using other cache types, such as shared memory,
  but files are more thoroughly supported.
• crypt hash
• A one way hash used to authenticate users. While
  more secure than plain text, it is fairly easy to
  decrypt for an experienced cracker.
• GSS-API
• The Generic Security Service Application Program
  Interface RFC-2743 is a set of functions which
  provide security services which clients can use
  to authenticate to servers and which servers can
  use to authenticate to clients without specific
  knowledge of the underlying mechanism. If a
  network service (such as IMAP) uses GSS-API, it
  can authenticate using Kerberos.
• key
• Data used when encrypting or decrypting other
  data. Encrypted data cannot be decrypted without
  the proper key or extremely good guessing.
• Key Distribution Center (KDC)
• A service that issues Kerberos tickets, usually
  run on the same host as the Ticket Granting
  Server
• key table or keytab
• A file that includes an unencrypted list of
  principals and their keys. Servers retrieve the
  keys they need from keytab files instead of using
  kinit. The default keytab file is
  /etc/krb5.keytab. The KDC administration server,
  /usr/kerberos/sbin/kadmind, is the only service
  that uses any other file (it uses
  /var/kerberos/krb5kdc/kadm5.keytab).

5
Terminology (cont.)

• kinit
• The kinit command allows a principal who has
  already logged in to obtain and cache the initial
  Ticket Granting Ticket (TGT). For more on using
  the kinit command, see its man page.
• principal
• The principal is the unique name of a user or
  service that can authenticates using Kerberos. A
  principal's name is in the form
  root/instance_at_REALM. For a typical user, the
  root is the same as their login ID. The instance
  is optional. If the principal has an instance, it
  is separated from the root with a forward slash
  ("/"). An empty string ("") is considered a valid
  instance (which differs from the default NULL
  instance), but using it can be confusing. All
  principals in a realm have their own key, which
  for users is derived from a password or is
  randomly set for services.
• realm
• A network that uses Kerberos, composed of one or
  more servers called KDCs and a potentially large
  number of clients.
• service
• A program accessed over the network.
• ticket
• A temporary set of electronic credentials that
  verify the identity of a client for a particular
  service.
• Ticket Granting Service (TGS)
• A server that issues tickets for a desired
  service which are in turn given to users for
  access to the service. The TGS usually runs on
  the same host as the KDC
• Ticket Granting Ticket (TGT)
• A special ticket that allows the client to obtain
  additional tickets without applying for them from
  the KDC.
• unencrypted password
• A plain text, human-readable password.

6
What is Kerberos?

• Kerberos is an authentication service developed
  at MIT. Its purpose is to allow users and
  services to authenticate themselves to each
  other.
• There are many ways to establish one's identity
  to a service. The most familiar is the user
  password. One "logs in" to a server by typing in
  a user name and password, which ideally only the
  user (and the server) know. The server is thus
  convinced that the person attempting to access it
  really is that user.
• The password must transit that network in the
  clear--that is, unencrypted. That means that
  anyone listening in on the network can intercept
  the password, and use it to impersonate the
  legitimate user.
• The key innovation underlying Kerberos is the
  notion that the password can be viewed as a
  special case of a shared secret--something that
  the user and the service hold in common, and
  which (again ideally) only they know.
  Establishing identity shouldn't require the user
  to actually reveal that secret
• In Kerberos, that secret is used as an encryption
  key. In the simplest case, the user takes
  something freshly created, like a timestamp (it
  need not be secret), and encrypts it with the
  shared secret key. This is then sent on to the
  service, which decrypts it with the shared key,
  and recovers the timestamp. If the user used the
  wrong key, the timestamp won't decrypt properly,
  and the service can reject the user's
  authentication attempt.
• Ref http//www.isi.edu/brian/security/kerberos.h
  tml

7
Basics of Kerberos

• Kerberos's fundamental approach is to create a
  service whose sole purpose is to authenticate.
  This is that it frees the services from having to
  maintain their own user account records.
• The key to this approach is that both user and
  service implicitly trust the Kerberos
  authentication server (AS) the AS thus serves as
  an introducer for them.
• In order for this to work, both the user and the
  service must have a shared secret key registered
  with the AS such keys are typically called
  long-term keys, since they last for weeks or
  months.
• Steps in authenticating a user to an end service.
• (1) User sends a request to the AS, asking it to
  authenticate him to the service.
• (2) AS generates a new, random secret key that
  will be shared only by the user and the service.
  It sends the user a two-part message. One part
  contains the random key along with the service's
  name, encrypted with the user's long-term key
  (credentials) the other part contains that same
  random key along with the user's name, encrypted
  with the service's long-term key (ticket).
• (3) User generates a fresh message, such as a
  timestamp, and encrypts it with the session key.
  This message is called the authenticator. He
  sends the authenticator, along with the ticket,
  to the service. The service decrypts the ticket
  with its long-term key, recovers the session key,
  which is in turn used to decrypt the
  authenticator. The service trusts the AS, so it
  knows that only the legitimate user could have
  created such an authenticator.

8
The Ticket Granting Server

• One of the inconveniences of It can be
  inconvenient if multiple services are used.
• Kerberos resolves this problem by introducing a
  new service, called the ticket granting server
  (TGS). The TGS is logically distinct from the AS,
  although they may reside on the same physical
  machine. (They are often referred to collectively
  as the KDC--the Key Distribution Center, from
  Needham and Schroeder 1.) The purpose of the
  TGS is to add an extra layer of indirection so
  that the user only needs to enter in a password
  once the ticket and session key obtained from
  that password is used for all further tickets.
• So, before accessing any regular service, the
  user requests a ticket from the AS to talk to the
  TGS. This ticket is called the ticket granting
  ticket, or TGT it is also sometimes called the
  initial ticket. The session key for the TGT is
  encrypted using the user's long-term key, so the
  password is needed to decrypt it from the AS's
  response to the user.
• After receiving the TGT, any time that the user
  wishes to contact a service, he requests a ticket
  not from the AS, but from the TGS. Furthermore,
  the reply is encrypted not with the user's secret
  key, but with the session key that came with the
  TGT, so the user's password is not needed to
  obtain the new session key (the one that will be
  used with the end service).
• The advantage this provides is that while
  passwords usually remain valid for months at a
  time, the TGT is good only for a fairly short
  period, typically eight or ten hours. Afterwards,
  the TGT is not usable by anyone, including the
  user or any attacker. This TGT, as well as any
  tickets that you obtain using it, are stored in
  the credentials cache.
• 1 R. M. Needham and M. D. Schroeder, "Using
  Encryption for Authentication in Large Networks
  of Computers," Communications of the ACM, Vol. 21
  (12), pp. 993-99. Last modified 30 March 2006.

9
Cross-Realm Authentication

• As the network grows, the number of requests
  grows with it, and the AS/TGS becomes a
  bottleneck in the authentication process. For
  this reason, it often makes sense to divide the
  world into distinct realms. These divisions are
  often made on organizational boundaries, although
  they need not be. Each realm has its own AS and
  TGS.
• To allow for cross-realm authentication--that is,
  to allow users in one realm to access services in
  another--it is necessary first for the user's
  realm to register a remote TGS (RTGS) in the
  service's realm. Such an association typically
  (but not always) goes both ways, so that each
  realm has an RTGS in the other realm. This now
  adds a new layer of indirection to the
  authentication procedure First the user contacts
  the AS to access the TGS. Then the TGS is
  contacted to access the RTGS. Finally, the RTGS
  is contacted to access the end service.
• Actually, it can be worse than that. In some
  cases, where there are many realms, it is
  inefficient to register each realm in every other
  realm. Instead, there is a network of realms, so
  that in order to contact a service in another
  realm, it is sometimes necessary to contact the
  RTGS in one or more intermediate realms. These
  realms are called the transited realms, and their
  names are recorded in the ticket. This is so the
  end service knows all of the intermediate realms
  that were transited, and can decide whether or
  not to accept the authentication. (It might not,
  for instance, if it believes one of the
  intermediate realms is not trustworthy.)
• This feature is new to Kerberos in Version 5. In
  Version 4, only peer-to-peer cross-realm
  authentication was permitted. In principle, the
  Version 5 approach allows for better scaling if
  an efficient hierarchy of realms is set up in
  practice, realms exhibit significant locality,
  and they mostly use peer-to-peer cross-realm
  authentication anyway. However, the advent of
  public-key cryptography for the initial
  authentication step (for which the certificate
  chain is recorded in the ticket as transited
  "realms") may again justify the inclusion of this
  mechanism.

10
Obtaining a Session key and Ticket Granting
Ticket (TGT)
Invents key SA Finds Alices master
KA TGTKKDCAlice,SA
AS_REQ
Alice, Password
Alice
Workstation
KDC
AS_REP
KA Alices master key SA Session key for
Alice TGT Session key, users name, expiration
time encrypted with KDCs master key AS
Authentication server TGS Ticket Granting Server
KASA,TGT
KDC
AS TGS
11
Alice Asks to Talk to a Remote Node

Alice wants to talk to Bob TGTKKDCAlice,
SA AuthenticatorSAtimestamp
Invents key KAB Decrypts TGT to get SA Decrypts
authenticator Verifies timestamp Finds Bobs
master key KB Ticket to BobKBAlice,KAB
rlogin Bob
TGS_REQ
Alice
Workstation
TGS
TGS_REP
SABob, KAB, ticket to Bob
Ticket to Bob KBAlice, KAB AuthenticatorKAB
timestamp
Decrypts ticket to get KAB Decrypts
authenticator Verifies timestamp
AP_REP
KABtimestamp1
12
Interrealm Authentication
Realm B
Realm A
Bob
Alice
KDC B
KDC A
TGS_REQ
Alice
KDC A
credentials
TGS_REQ
KDC B
credentials
Bob
AP_REQ
13
Formats - Example

• Tickets KDC issues a ticket to Alice for Bob

Alices name Alices instance Alices
realm Alices network layer address Session key
for Alice Bob Ticket lifetime, units of 5
minutes KDCs timestamp when ticket made Bobs
name Bobs instance Pad of 0s to make ticket
length multiples of eight octets
14
Kerberos V5

• Delegation of Rights Ability to give someone
  else access to things you are authorized to
  access.
• Usually limited in time or limited in scope
• Kerberos V5 allows delegation by Alice asking TGT
  with a network layer address (or multiple
  addresses) different from hers.
• First, Alice gets a normal session key and a TGT
  with her network layer.
• When later Alice decides to delegate to Bob, she
  requests a new TGT from the KDC---with a new
  network layer address

15
Hierarchy of realms
A
C
B
G
D
E
H
I
F
J
16
Kerberos Architecture

• Kerberos architecture consists of three key
  components
• client software
• authentication server software
• application server software

17
Standards

• SSL/TLS

18
Goals of SSL

• Authenticating the client and server to each
  other the SSL protocol supports the use of
  standard key cryptographic techniques (public key
  encryption) to authenticate the communicating
  parties to each other. Though the most frequent
  application consists in authenticating the
  service client on the basis of a certificate, SSL
  may also use the same methods to authenticate the
  client.
• Ensuring data integrity during a session, data
  cannot be either intentionally or unintentionally
  tampered with.
• Securing data privacy data in transport between
  the client and the server must be protected from
  interception and be readable only by the intended
  recipient. This prerequisite is necessary for
  both the data associated with the protocol itself
  (securing traffic during negotiations) and the
  application data that is sent during the session
  itself. SSL is in fact not a single protocol but
  rather a set of protocols that can additionally
  be further divided in two layers
• the protocol to ensure data security and
  integrity this layer is composed of the SSL
  Record Protocol,
• the protocols that are designed to establish an
  SSL connection three protocols  are used in this
  layer the SSL Handshake Protocol, the SSL
  ChangeCipher SpecPprotocol and the SSL Alert
  Protocol.
• TLS (Transport level security protocol) is a
  revised version of SSL v3 introduced by IETF.

19

SSL Protocol Stack
20
SSL Protocol Summary

• The SSL Record protocol It is used to transfer
  any data within a session - both messages and
  other SSL protocols (for example the handshake
  protocol), as well as for any application data.
• The Alert Protocol It is used by parties to
  convey session messages associated with data
  exchange and functioning of the protocol. Each
  message in the alert protocol consists of two
  bytes. The first byte always takes a value,
  warning (1) or fatal (2) , that determines
  the severity of the message sent. Sending a
  message having  a fatal status by either party
  will result in an immediate termination of the
  SSL session. The next byte of the message
  contains one of the defined error codes, which
  may occur during an SSL communication session.
• The ChangeCipher Spec protocol This protocol is
  the simplest SSL protocol. It consists of a
  single message that carries the value of 1. The
  sole purpose of this message is to cause the
  pending session state to be established as a
  fixed state, which results, for example, in
  defining the used set of protocols. This type of
  message must be sent by the client to the server
  and vice versa. After exchange of messages, the
  session state is considered agreed. This message
  and any other SSL messages are transferred using
  the SSL record protocol.
• The handshake protocol It constitutes the most
  complex part of the SSL protocol. It is used to
  initiate a session between the server and the
  client. Within the message of this protocol,
  various components such as algorithms and keys
  used for data encryption are negotiated. Due to 
  this protocol, it is possible to authenticate the
  parties to each other and negotiate appropriate
  parameters of the session between them.

21
Creating a packet under SSL
http//www.windowsecurity.com/articles/Secure_Sock
et_Layer.html
22
Handshake in SSL

23
Basic SSL Protocol

• Msg 1 Alice says she would like to talk and
  provides a list of cryptographic algorithms she
  supports, along with a randon number RAlice
  (later used to form a session key)
• Msg 2 Bob sends Alice his certificate, a random
  number RBob (also used to form the session key),
  and one of the ciphers listed in Msg1 that Bob
  supports.
• Msg 3 Alice chooses a random number S, computes
  Kf(S, RAlice,Rbob), and sends S encrypted with
  Bobs public key
• Bob also computes Kf(S, RAlice,Rbob)
• Both Alice and Bob use a key derived from K
  different keys are used in each direction in
  each direction there are three keys for
  encryption, integrity, and IV.
• Msg 4 Bob proves that it knows the session key

24
Encrypted Records

• Integrity HMAC based on MD5 or SHA-1
• Encryption Any encryption algorithm using block
  ciphers in CBC mode except RC4.

HMAC Computed on this
Integrity key
Seq
Record HDR
Record Data
Record HDR
Record Data
HMAC
Pad
Encrpyt
Encryption key
Record HDR
Encrypted Integrity-protected record
25
Standards

• Public Key Infrastructure (PKI)

26
Terminology

• Issuer Who issues a certificate (Certificate
  authority or CA)
• Subject---to whom a certificate is issued
• Verifier ---one who verifies if a certificate is
  valid
• Reluing party or service provider
• Trust anchor---CA trusted by a relying party

27
PKI Trust models

• Monopoly model (single CA for the entire world
  very unrealistic)
• Monopoly Registration authorities (RAs)
• Delegated CAs A tree of CAs where a parent CA
  issues certificates to child CAs
• Oligarchy Used in browsers Many trusted CAs
• Anarchy model Used by PGP Any one can sign a
  certificate
• Name constraints Trust a CA for certain name
  domains
• Bottom-up with name constraints Parent and child
  certify ecah other cross-certificates are also
  possible in the hierarchy of forests

28
Revocation

• If a key has been compromised or if someone gets
  fired from an organization, it is important to
  revoke their certificate.
• Similar to what happens when a credit card is
  stolen or lost

29
Revocation Mechanisms

• CRLS certificate Revocation Lists
• Delta CRLs lists changes from last complete CRL
• First valid certificate
• On-line revocation server (OLRS or OCRL)
• Good lists vs. Bad lists

30
X.509 and PKIX

• PKIX I a profile of X.509---it specifies which
  options should be supported.

31

• X.509 - Certificate format
• Version (v10, v21, v32)
• Serial number
• Signature Algorithm ID
• Issuer Name
• Validity period(Start and expiry date/time)
• Subject Name
• Subject public key info(Algorithm ID and public
  key value)
• Issuer Unique ID (optional)
• Subject Unique ID (optional)
• Extensions (optional)Type - Critical/Non
  critical - Field value
• SignatureAlgorithm ID and signature value

32
PKI Tutorials

• http//www.ncvhs.hhs.gov/050113p3.pdf
• http//www.cs.auckland.ac.nz/pgut001/pubs/pkituto
  rial.pdf
• http//www.cypherpunks.to/peter/part2.pdf

33
Standards

• Pretty Good Privacy (PGP)

34
How PGP works

• PGP uses both public-key cryptography and
  symmetric key cryptography, and includes a system
  which binds the public keys to user identities.
• The first version of this system is generally
  known as a web of trust as opposed to developed
  later X.509 system with top-down approach based
  on certificate authority. Later versions of PGP
  have included something more akin to a public key
  infrastructure (PKI) that includes certificate
  authority.
• PGP uses asymmetric key encryption algorithms. In
  these, the recipient must have previously
  generated a linked key pair, a public key, and a
  private key. The sender uses the recipient's
  public key to encrypt a shared key (aka a secret
  key or conventional key) for a symmetric cipher
  algorithm. That key is used, finally, to encrypt
  the plaintext of a message. Many PGP users'
  public keys are available to all from the many
  PGP key servers around the world which act as
  mirror sites for each other.
• The recipient of a PGP-protected message decrypts
  it using the session key for a symmetric
  algorithm. That session key was, of course,
  included in the message in encrypted form and was
  itself decrypted using the recipient's private
  key. Use of two ciphers in this way is sensible
  because of the very considerable difference in
  operating speed between asymmetric key and
  symmetric key ciphers (the differences are often
  1000 times).
• A similar strategy is (by default) used to detect
  whether a message has been altered since it was
  completed, or (also by default) whether it was
  actually sent by the person/entity claimed to be
  the sender.
• To do both at once, the sender uses PGP to 'sign'
  the message with either the RSA or DSA signature
  algorithms. To do so, PGP computes a hash (also
  called a message digest) from the plaintext, and
  then creates the digital signature from that hash
  using the sender's private key. The message
  recipient computes a message digest over the
  recovered plaintext, and then uses the sender's
  public key and the signed message digest value
  with the signature algorithm. If the signature
  matches the received plaintext's message digest,
  it must be presumed (to a very high degree of
  confidence) that the message received has not
  been tampered with, either deliberately or
  accidentally, since it was properly signed.
• http//en.wikipedia.org/wiki/OpenPGP

35
How PGP works (Cont.)

• It is critical that the public key one uses to
  send messages to some person or entity actually
  does 'belong' to the intended recipient.
• Users must also verify by some means that the
  public key in a certificate actually does belong
  to the person/entity claiming it. From its first
  release, PGP has used a web of trust. A given
  public key (or more specifically, information
  binding a person to a key) may be digitally
  signed by a third party to attest the association
  between the person and the key. There are several
  levels of confidence that can be expressed in
  this signature.
• In the (more recent) OpenPGP specification, trust
  signatures can be used to support creation of
  certificate authorities. A trust signature
  indicates both that the key belongs to its
  claimed owner and that the owner of the key is
  trustworthy to sign other keys at one level below
  their own.
• A level 0 signature is comparable to a web of
  trust signature, since only the validity of the
  key is certified.
• A level 1 signature is similar to the trust one
  has in a certificate authority because a key
  signed to level 1 is able to issue an unlimited
  number of level 0 signatures.
• A level 2 signature is highly analogous to the
  trust assumption users must rely on whenever they
  use the default certificate authority list in
  Internet Explorer it allows the owner of the key
  to make other keys certificate authorities.
• PGP has also included a way to 'revoke' identity
  certificates which may have become invalid. More
  recent PGP versions have also supported
  certificate expiration dates.
• The problem of correctly identifying a public key
  as belonging to some other user is not unique to
  PGP. All public key and private key cryptosystems
  have the same problem.

36
Downloading PGP etc.

• PGP 6.5.8 Tutorial
• http//www.pitt.edu/poole/PGP.htmwaiting
• E-mail privacy and PGP Tutorial
• http//www.emailprivacy.info/privacy_pgp

37
Secure Shell (SSH)
38
Introduction

• Ssh (Secure Shell) is a program to log into
  another computer over a network, to execute
  commands in a remote machine, and to move files
  from one machine to another. It provides strong
  authentication and secure communications over
  unsecure channels. It is intended as a
  replacement for rlogin, rsh, and rcp.
• Ssh protects against
• IP spoofing, where a remote host sends out
  packets which pretend to come from another,
  trusted host. Ssh even protects against a spoofer
  on the local network, who can pretend he is your
  router to the outside.
• IP source routing, where a host can pretend that
  an IP packet comes from another, trusted host.
• DNS spoofing, where an attacker forges name
  server records
• Interception of cleartext passwords and other
  data by intermediate hosts.
• Manipulation of data by people in control of
  intermediate hosts
• SSH does not protect against anything that
  compromises your host's security in some other
  way. Once an attacker has gained root access to a
  machine, he can then subvert ssh, too.

39
How SSH works?

• Summary All communications are encrypted using
  IDEA or one of several other ciphers (three-key
  triple-DES, DES, RC4-128, TSS, Blowfish).
  Encryption keys are exchanged using RSA, and data
  used in the key exchange is destroyed every hour
  (keys are not saved anywhere). Every host has an
  RSA key which is used to authenticate the host
  when RSA host authentication is used. Encryption
  is used to protect against IP-spoofing public
  key authentication is used to protect against DNS
  and routing spoofing. RSA keys are also used to
  authenticate hosts.
• http//www.rz.uni-karlsruhe.de/ig25/ssh-faq/

40
Details

• cash/home/mukka/.ssh2ssh-keygen
• Generating 2048-bit dsa key pair
• 2 oOo.oOo.oOo.
• Key generated.
• 2048-bit dsa, mukka_at_cash.cs.odu.edu, Wed Sep 27
  2006 101400 -0500
• Passphrase
• Again
• Private key saved to /home/mukka/.ssh2/id_dsa_2048
  _a
• Public key saved to /home/mukka/.ssh2/id_dsa_2048_
  a.pub
• cash/home/mukkassh2 dilbert
• mukka's password
• Authentication successful.
• Last login Wed Sep 27 2006 100940 -0500 from
  dhcp-87.cs.odu.
• Sun Microsystems Inc. SunOS 5.9 Generic
  May 2002
• You have new mail.
• Sun Microsystems Inc. SunOS 5.9 Generic
  May 2002
• You have new mail.
• cash/home/mukka

41
Procedure

• Ssh2 connects and logs in on the specified host.
  The user must prove her identity to the
  remote machine using some authentication method.
• Public-key authentication is based on the use
  of digital signatures. Each user creates a
  public / private key pair for authentication
  purposes. The server knows the users public
  key, and only the user has the private key.
• When the user tries to authenticate
  herself, the server checks for
  filenames of matching public keys and sends a
  challenge to the user end. The user is
• authenticated by signing the challenge
  using the private key.
• If other authentication methods fail, ssh2 will
  prompt for a password. Since all communication
  is encrypted, the pass-word will not be available
  for eavesdroppers.
• When the user's identity has been accepted by
  the server, the server either executes the
  given command, or logs in on the machine and
  gives the user a normal shell. All communication
  with the remote command or shell will be
  automatically encrypted.

42
Difference between SSH and SSL

• Main objective SSL was designed to secure web
  sessions SSH was designed to replace telnet and
  FTP both can do more.
• SSL is a drop-in with a number of uses. It
  front-ends HTTP to give HTTPS. It can also do
  this for POP3, SMTP, IMAP, and just about any
  other well-behaved TCP application. It is easy
  for most programmers who are creating network
  applications from scratch to just grab an SSL
  implementation and bundle it with their app to
  provide encryption when communicating across the
  network via TCP.
• SSH is designed to do a lot of different
  things, most of which revolve around setting up a
  secure tunnel between hosts. Some implementations
  of SSH rely on SSL libraries - this is because
  SSH and SSL use many of the same encryption
  algorithms (i.e. TripleDES).

43
Difference between SSH and SSL (Cont.)

• SSL by itself gives you nothing - just a
  handshake and encryption. You need an application
  to drive SSL to get real work done.
• SSH by itself does a whole lot of useful
  stuff that allows users to perform real work. Two
  aspects of SSH are the console login (telnet
  replacement) and secure file transfers (ftp
  replacement), but you also get an ability to
  tunnel (secure) additional applications, enabling
  a user to run HTTP, FTP, POP3, and just about
  anything else THROUGH an SSH tunnel.
• Without interesting traffic from an application,
  SSL does nothing. Without interesting traffic
  from an application, SSH brings up an encrypted
  tunnel between two hosts which allows you to get
  real work done through an interactive login
  shell, file transfers, etc.
• HTTPS does not extend SSL, it uses SSL to do HTTP
  securely. SSH does much more than SSL, and you
  can tunnel HTTPS through it! Just because both
  SSL and SSH can do TripleDES doesn't mean one is
  based on the other.
• http//www.rpatrick.com/tech/ssh-ssl/

44
More differences

• SSL server authentication is optional the
  protocol supports fully anonymous operation, in
  which neither side is authenticated. Such
  connections are inherently vulnerable to
  man-in-the-middle attacks.
• In SSH, server authentication is mandatory, which
  protects against such attacks. Of course, it is
  always possible for a client to skip the step of
  verifying that the public key supplied by the
  server actually belongs to the entity the client
  intended to contact (e.g. using the
  /etc/ssh_known_hosts file). However, SSH at least
  demands going through the motions.
• In SSL both client and server authentication are
  done with X.509 public-key certificates. This
  makes SSL a bit more cumbersome to use than SSH
  in practice, since it requires a functioning
  public-key infrastructure (PKI) to be in place,
  and certificates are more complicated things to
  generate and manage than SSH keys. However, a PKI
  system provides scalable key management for your
  trouble, which SSH currently lacks.
• SSL does not provide the range of client
  authentication options that SSH does public-key
  is the only option.
• SSL does not have the extra features provided by
  the other SSH component the SSH Connection
  Protocol (SSH-CONN). SSH-CONN uses the underlying
  SSH-TRANS connection to provide muliple logical
  data channels to the application, as well as
  support for remote program execution, terminal
  management, tunnelled TCP connections, flow
  control, etc.
• http//www.snailbook.com/faq/ssl.auto.html

45
Standards

• IPSec

46

• An Illustrated Guide to IPsec
• Practical IPSEC - AUG2002 Tutorial

47
Introduction

• IPsec---standard for real-time communication
  security
• Security association (SA)---cryptographically
  protected connection---unidirectional---each end
  keeps track of the cryptographic information
  (including a sequence number) associated with
  that SA in a database.
• Each SA is associated with a security parameter
  index (similar to virtual circuit ID in
  networks). It is determined by the destination.
• IPsec policy database This indicates what
  actions (encryption/integrity check/etc.) should
  be taken for what type of packets/destinations
  etc.

48
Introduction (Cont.)

• Two types of IPsec headers---AH and ESP
• AH---Authentication Header (integrity protection
  only)
• ESP---Encapsulating Security Payload (encryption
  and/or integrity)
• Two modes of protection---Tunnel and transport
• Transport mode---add IPsec information between IP
  header and the rest of the packet
• Tunnel mode---keep the original IP packet as it
  is and add an additional IP header and IPsec
  information outside

49
Transport mode

• It is the default mode for IPSec
• It is used for end-to-end communications (for
  example, for communications between a client and
  a server).
• Here, IPSec encrypts only the IP payload.
• It provides the protection of an IP payload
  through an AH or ESP header. (Typical IP payloads
  are TCP segments (containing a TCP header and TCP
  segment data), a UDP message (containing a UDP
  header and UDP message data), and an ICMP message
  (containing an ICMP header and ICMP message
  data)).
• http//technet2.microsoft.com/WindowsServer/en/lib
  rary/c3a956bf-704b-4980-9655-762985e380f61033.mspx
  ?mfrtrue

50
Tunnel Mode

• Common use---firewall to firewall, or end node to
  firewall
• The firewall at source changes the source and
  destination addresses in the new IP header. The
  destination firewall forwards the original IP
  packet onwards.
• Transport mode may be superfluous with tunnel
  mode

51

• AH (Authentication Header)
• Provides authentication (and not encryption)
• It protects the data and the IP header
• ESP (Encapsulating Security Payload)
• Allows for encryption and/or integrity protection

52
IPsec IKE (Internet Key Exchange)

• Protocol for mutual authentication and
  establishing a shared key to create a security
  association (SA).
• Main idea Do mutual authentication using some
  sort of long term key (pre-shared key,
  public-signature-only key, or public encryption
  key) establish a session key
• Phase 1 Mutual authentication and session key
  establishment
• Phase 2 Multiple SAs between the authenticated
  entities are established
• Why multiple SAs? Set up different SAs for
  different traffic flows (conversations0.

53
IKE Phase 1

• Aggressive mode
• Main mode same exchange in 6 messages
• Encryption algorithm (e.g., DES, 3DES, IDEA)
• Hash algorithm (e.g., MD5, SHA-1)
• Authentication method (e.g., pre-shared keys, RSA
  public key signature, DSS, RSA public key
  encryption)
• Diffie-Hellman group (e.g., modular
  exponentiation with specified g and p, elliptic
  curve with specific parameters)

54
Standards

• S/MIME

55
What is MIME?

• Multipurpose Internet Mail Extensions
• It is the official proposed standard format for
  extended Internet electronic mail.
• Internet e-mail messages consist of two parts,
  the header and the body.
• The header forms a collection of field/value
  pairs structured to provide information essential
  for the transmission of the message. The body is
  normally unstructured unless the e-mail is in
  MIME format.
• MIME defines how the body of an e-mail message is
  structured. The MIME format permits e-mail to
  include enhanced text, graphics, audio, and more
  in a standardized manner via MIME-compliant mail
  systems.
• However, MIME itself does not provide any
  security services. The purpose of S/MIME is to
  define such services, following the syntax given
  in PKCS 7 for digital signatures and encryption.
  The MIME body section carries a PKCS 7 message,
  which itself is the result of cryptographic
  processing on other MIME body sections.

56

• S/MIME (Secure / Multipurpose Internet Mail
  Extensions) is a protocol that adds digital
  signatures and encryption to Internet MIME.
• S/MIME has been endorsed by a number of leading
  networking and messaging vendors, including
  ConnectSoft, Frontier, FTP Software, Qualcomm,
  Microsoft, Lotus, Wollongong, Banyan, NCD,
  SecureWare, VeriSign, Netscape, and Novell.

57

• http//www.marknoble.com/tutorial/smime/smime.aspx
  
• http//www.dartmouth.edu/pkilab/pages/Using_SMIME
  _e-mail.html