Authentication

Comments (0)

Transcript of Authentication

AuthenticationRemote user authentication principlesRemote user-authentication using symmetric encryptionKerberosRemote user-authentication using Asymmetric encryptionFederated identity managementUser Authenticationis 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 stepVerification stepPresenting an identifier to the security systemPresenting 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:

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

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

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

4-Something the individual does (dynamic biometrics): Examples include recognition by voice pattern, handwriting characteristics, and typing rhythmMutual 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 timelinessExamples of Replay Attacks:1- Simple replay.2- Repetition that can be logged.3- Repetition that cannot be detected.4- Backward replay without modification.

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 KDCKDC generates session keys used for connections between partiesmaster keys used to distribute these to them

Needham-Schroeder Protocolis 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.

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

1. A->KDC: IDA || IDB ||

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

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

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

5. 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 + ∆ t2Where ∆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

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.

Kerberos 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 correctlyA user may gain access to a particular workstation and pretend to be another user operationg from that workstationA user may alter the network address of a workstation and thus impersonate another workstationA 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:(1) 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).(2) Require that client systems authenticate themselves to servers, but trust the client systems conserning the identity of the user.(3) 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 RequirementsSecure: a network eavesdropper should not be able to obtain the required information for impresonating a user.Reliable: 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.

Transparent: the user should not be aware that authentication is taking place, except for the entering of the password. Scalable: 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 DialogueTwo major problems remain in previous simple protocol1- 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.2-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).

1. 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.2. 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. 3. 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.4. 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.5. 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 5Version 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 wideaccess 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 authentication.

Identity Federationan 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 onagreed standards and mutual levels of trust to securely share digital identities.

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

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

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

The first principle within federated identity management is the active protection of user informationProtect the user’s credentials only the IdP ever handles the credentialProtect the user’s identity information ,including identifier customized set of information released to each SP SAMLSecurity 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 Realmsa Kerberos environment consists of:a Kerberos servera number of clients, all registered with serverapplication servers, sharing keys with server-this is termed a realmtypically a single administrative domain-if have multiple realms, their Kerberos servers must share keys and trust