Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.



No description

Alaa Zidan

on 31 January 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Authentication

Remote user authentication principles
Remote user-authentication using symmetric encryption
Remote user-authentication using Asymmetric encryption
Federated identity management
User Authentication
is the fundamental building block and the primary line of defense and is the basis for most types of access control and for user accountability.

authentication process
Identification step
Verification step
Presenting an identifier to the security system
Presenting or generating authentication information that
corroborates the binding between the entity and the identifier

There are four general means of authenticating a user’s identity, which can be used alone or in combination:

Something the individual knows
: answers Examples include a password, a personal identification number (PIN), or to a prearranged set of questions.

Something the individual possesses
: Examples include cryptographic keys, electronic key cards, smart cards, and physical keys. This type of authenticator is referred to as a token.

Something the individual is (static biometrics)
: Examples include recognition by fingerprint, retina, and face.

Something the individual does (dynamic biometrics)
: Examples include recognition by voice pattern, handwriting characteristics, and typing rhythm
Mutual authentication or two-way authentication
 refers to two parties authenticating each other suitably.
Such protocols enable communicating parties to satisfy themselves mutually about each other’s identity and to exchange session keys.
Central to the problem of authenticated key exchange are two issues: confidentiality and timeliness
Examples of Replay Attacks:
Simple replay.
Repetition that can be logged.
Repetition that cannot be detected.
Backward replay without modification.

Approaches for coping with Replay Attack:
use of sequence numbers (generally impractical)
timestamps (needs synchronized clocks)
challenge/response (using unique nonce)

One-Way Authentication

Its chief benefit, is that it is not necessary for the sender and receiver to be online at the same time.

One application for which encryption is growing in popularity is electronic mail

The “envelope” or header of the e-mail message must be in the clear, so that the message can be handled by the store-and-forward e-mail protocol, such as the Simple Mail Transfer Protocol (SMTP) or X.400.

However, it is often desirable that the mail-handling protocol not require access to the plaintext form of the message because that would require trusting the mail-handling mechanism.

The e-mail message should be encrypted such that the mail-handling system is not in possession of the decryption key.

A second requirement is that of authentication Typically, the recipient wants some assurance that the message is from the alleged sender.

Mutual Authentication
as discussed previously can use a two-level hierarchy of keys.
usually with a trusted Key Distribution Center (KDC)
each party shares own master key with KDC
KDC generates session keys used for connections between parties
master keys used to distribute these to them

Needham-Schroeder Protocol
is the original, basic key exchange protocol. Used by 2 parties who both trusted a common key server, it gives one party the info needed to establish a session key with the other.
Since the key server chooses the session key, it is capable of reading/forging any messages between A&B.

protocol overview is:
A->KDC: IDA || IDB || N1
KDC -> A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
A -> B: EKb[Ks||IDA]
B -> A: E(Ks,N2])

A -> B: E(Ks,,f(N2))
Despite the handshake of steps 4 and 5, the protocol is still vulnerable to a form of replay attack.
Denning [DENN81, DENN82] proposes to overcome this weakness by a modification to the Needham/Schroeder protocol that includes the addition of a timestamp to steps 2 and 3.

A->KDC: IDA || IDB ||

KDC -> A: EKa[Ks || IDB ||T|| N1 || EKb[Ks||IDA||T] ]

A -> B: EKb[Ks||IDA||T]

B -> A: E(Ks,N2])

A -> B: E(Ks,,f(N1))

T is a timestamp that assures A and B that the session key has only just been generated.

A and B can verify timeliness by checking that:
│clock - T│< ∆t1 + ∆ t2
Where ∆t1 is the estimated normal discrepancy between the KDC’s clock and the local clock (at A or B) and ∆t2 is the expected network delay time.

The Denning protocol seems to provide an increased degree of security compared to the Needham/Schroeder protocol however, a new concern is raised that this new scheme requires reliance on clocks that are synchronized throughout the network.

The problem occurs when a sender’s clock is ahead of the intended recipient’s clock. In this case, an opponent can intercept a message from the sender and replay it later when the timestamp in the message becomes current at the recipient’s site this replay could cause unexpected results. Gong refers to such attacks as suppress-replay attacks.

In [KEHN92], an attempt is made to respond to the concerns about suppress replay attacks

This protocol provides an effective, secure means for A and B to establish a session with a secure session key. Furthermore, the protocol leaves A in possession of a key that can be used for subsequent authentication to B, avoiding the need to contact the authentication server repeatedly but within the time limit established by the protocol.

In all the foregoing, the time specified in Tb is a time relative to B’s clock thus, this timestamp does not require synchronized clocks, because B checks only self-generated timestamps.

Using symmetric encryption, with some refinement, the KDC strategy is a candidate for encrypted electronic mail because we wish to avoid requiring that the recipient be on line at the same time as the sender

A->KDC: IDA || IDB || N1
KDC -> A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
A -> B: EKb[Ks||IDA] || EKs[M]

This approach guarantees that only the intended recipient of a message will be able to read it, and also provides a level of authentication that the sender is A.

the protocol does not protect against replays.

You could rely on timestamp in the message, though email delays make this problematic.

is an authentication service developed in MIT.
There are two versions
version 4 (developed in 1988) is still in common use
version 5 (1994) corrects some security deficiencies of version 4 and has been issued a draft internet standard (RFC 1510)
The problem that Kerberos addresses is this:
”In an open distributed environment users at workstations wish to access services on servers distributed throughout the network. The servers must be able to restrict access to authorized users and be able to authenticate requests for service.”
In this environment a workstation can not be trusted to identify users correctly
A user may gain access to a particular workstation and pretend to be another user operationg from that workstation
A user may alter the network address of a workstation and thus impersonate another workstation
A user may eavesdrop on exchanges and use a replay attack to gain entrance to a server

three approaches to security
In a distributed architecture consisting of clients and severs three approaches to security can be envisioned:
Rely on each client workstation to assure the identity of its users and rely on each server to enforce security policy based on user identification (ID).
Require that client systems authenticate themselves to servers, but trust the client systems conserning the identity of the user.
Require the user to prove identity for each service invoked. Require that servers prove their identity to clients.
The two first approaches could be used in a small closed environment.
Third approach is supported by Kerberos: Kerberos assumes a distributed client/server architecture and and uses one or more Kerberos servers to provide an authentication service.

Kerberos Requirements
: a network eavesdropper should not be able to obtain the required information for impresonating a user.
: services rely on the availability of Kerberos access control, thus lack of availability of Kerberos is lack of availability of the services. Kerberos should employ a distributed server architecture with one system able to back up another.

: the user should not be aware that authentication is taking place, except for the entering of the password.
: the system should have a modular, distributed architecture to support large number of clients and servers

the AS creates a ticket that contains the user's ID and network address and the server's ID.
This ticket is encrypted using the secret key shared by the AS and this server
This ticket is then sent back to C.
C sends a message to V containing C's ID and the ticket.
V decrypts the ticket and verifies that the user ID in the ticket is the same as the unencrypted user ID in the message

A More Secure Authentication Dialogue
Two major problems remain in previous simple protocol
The user must reenter the password to gain access to each separate server since a new ticket is needed for each new service. We would of course like to have a scheme where the password is entered only once for one logon session.
The simple protocol involved a plaintect transmission of the password, making it easy for an opponent to use any service accessible to the user.
To solve these two problems we introduce a new server, the ticket-granting server (TGS)
a scheme for avoiding plaintext passwords and a new server, known as the ticket-granting server (TGS).

The client requests a ticket-granting ticket on behalf of the user by sending its user's ID and password to the AS, together with the TGS ID, indicating a request to use the TGS service.
The AS responds with a ticket that is encrypted with a key that is derived from the user's password. When this response arrives at the client, the client prompts the user for his or her password, generates the key, and attempts to decrypt the incoming message. If the correct password is supplied, the ticket is successfully recovered.
The client requests a service-granting ticket on behalf of the user. For this purpose, the client transmits a message to the TGS containing the user's ID, the ID of the desired service, and the ticket-granting ticket.
The TGS decrypts the incoming ticket and verifies the success of the decryption by the presence of its ID. It checks to make sure that the lifetime has not expired. Then it compares the user ID and network address with the incoming information to authenticate the user. If the user is permitted access to the server V, the TGS issues a ticket to grant access to the requested service.
The client requests access to a service on behalf of the user. For this purpose, the client transmits a message to the server containing the user's ID and the service-granting ticket. The server authenticates by using the contents of the ticket

Kerberos version 5
Version 4 was really intended to be used in a somewhat closed environment. Several environmental improvements are introduced in version 5 to make Kerberos a general purpose authentication service. Also several technical deficiencies are corrected.
Environmental shortcamings
Version 4 required the use of DES, in version 5 any encryption algorithm can be used.
Version 4 required the use of Internet Protocol, in version 5 any type of networking can be used.
Authentication forwarding: in version 5 a server can access other servers on behalf of the user by forwarding tickets.
Inter-realm authentication: In version 4 interoperability between N realms requires N2 Kerberos-to-Kerberos relationships. Version 5 supports a mechanism to reduce this number.
An important feature of Kerberos 5 is the use of ticket flags that are used to control many new supported features of version 5.
The Kerberos 5 protocol is presented in table 11.3 and the flags briefly listed in table 11.4.

Identity Management
* automated approach to provide enterprise wide
access to resources by employees and other authorized individuals.

* The focus of identity management is defining an identity for each user associating attributes with the identity, and enforcing a means by which a user can verify identity.
* The central concept of an identity management system is the use of
single sign-on (SSO).
* SSO enables a user to access all network resources after a single

Identity Federation
an extension of identity management to multiple security domains.
Such domains include autonomous internal business units, external business partners, and other third-party applications and services.

The goal is to provide the sharing of digital identities so that a user can be authenticated a single time and then access applications and resources across multiple domains.
domains are relatively autonomous or independent, no centralized control is possible.
cooperating organizations must form a federation based on
agreed standards and mutual levels of trust to securely share digital identities.

Federated Identity Management 
refers to the agreements, standards, and technologies
that enable the portability of identities, identity attributes, and entitlements
across multiple enterprises and numerous applications and supporting many thousands , even millions, of users .

an employee in one organization can use a single sign on
to access services across the federation with trust relationships associated with
the identity.
For example, an employee may log onto her corporate intranet and be
authenticated to perform authorized functions and access authorized services on that intranet .
The employee could then access their health benefits from an outside
health-care provider without having to reauthenticate.

Federated Identity architecture
In Federated Identity Management:
Identity Providers
(IdP) publish authentication and identity information about users
Service Providers
(SP) consume this information and make it available to an application
An IdP or SP is generically known as an entity

The first principle within federated identity management is the active protection of user information
Protect the user’s credentials only the IdP ever handles the credential
Protect the user’s identity information ,including identifier customized set of information released to each SP
Security Assertion Markup Language .
Is a secure XML base communication mechanism For communicating identities between organization.
Key thing about SAML is the primary use case it enable
internet SSO.
eliminates the need to maintain multiple authentication credentials such as passwords and multiple locations.

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


Alyaa el-okel
Sally Mahmoud
Alaa Kamel Zidan
Sara Abd El-Nasser
Full transcript