A Radical New Approach to (MUTUAL) AUTHENTICATION

RELative IDentity

Sanjay Deshpande <sanjay.deshpande@rel-id.com>

Dr. Pat Shankar <pat.shankar@rel-id.com>
Nanjundeashwar Ganapathy <eashwar@rel-id.com>
Identity Research Lab
REL-ID TECHNOLOGIES, INC. (A UNIKEN VENTURE)

Abstract
In this article, we present a fundamentally new identity framework – RELATIVE IDENTITY - which addresses and eliminates many
of the core problems faced by the current identity technologies. We postulate that authentication necessarily has to be mutual
and that the only valid way to perform mutual authentication is to make fundamental changes to the identity representation
framework. This can be accomplished by –
(a) Changing from end-point entity labeling (like in the case of login/password, biometric, digital certificates, 2-Way SSL
and a combination of these) – to labeling the relationship between the end-point entities (which inherently covers the
two end-points in its definition)
(b) Making the authentication protocol truly mutual – and thereby eliminating the susceptibility to man-in-the-middle
attacks and phishing

Identity and identification are central to any interaction, both in real and virtual (digital) systems, typically where the interaction
entails access to or manipulation of protected resource(s).

We firmly believe that any identity framework has to address the problem of establishing a mutually-authenticated secure
connection BEFORE initiating any data transaction using that connection.

Introduction
Identity and Authentication form the central piece of any information security solution/framework. Establishing identity using
an authentication protocol is the starting point for any secure transaction. In order to be able to establish identity (be it man or
machine), the entity must be characterized by a unique set of symbols (as per the adopted identity representation framework).
During the process of actually identifying / authenticating the entity, the same characteristics of the entity are observed and
matched against those that were captured earlier and associated with the entity.
The act of establishing identity is identification. Identity Systems must possess the capability represent, provide, maintain and
establish identity. The identity representation framework must ensure that it is extremely difficult to compromise the individual
identities it is used represent.
In this article we cover the following points:

1. Definition of RELative IDentity – the representation

2. Fundamental properties of identity (representation)
3. Proof that all authentication must necessarily be mutual ( that 1-way authentication basically flawed)
4. Fundamental properties of authentication / identification (the process of)
5. How is Relative Identity different from other identity schemes

The basic flaws and limitations in current identity technologies for websites prevalent in the World Wide Web SSL/Digital
Certificates (when used for AUTHENTICATION) become apparent in the context of the axiomatic frame of reference defined in
the following sections.

REL-ID: An Introduction 1
Definition of Relative Identity
The relative identity of an entity is
1. Distributed among the relationship of this entity with other entities. Each such valid relationship –
o Constitutes a unit “Relative Identity” – an important and inseparable constituent of the identities of each of
the entities sharing the valid relationship
o Contributes in the definition of the relative identity of each entity
o Exists only in the context of two (or more) entities who share a relationship.
2. Is the union/collection of all such “Relative Identities”
3. Is dynamic since new relationships may be established, while old relationships may be discarded, over time
4. Is associated with a set of labels/attributes/characteristics – immutable and mutable
o immutable - such as biometrics, which cannot be changed at will
o mutable - such as SSN which are awarded for a life time, log in passwords, bank account numbers which are
changed quite often

In practical implementations of identity based transactions, one is concerned only with the specific (relevant) relative identity
and associated attributes, and hence the rest of the identity of representation is not susceptible to identity theft.

As is evident from the above definition, the concept of identity in the prevalent conventional identity systems that deal with
only labels/attributes/characteristics – “What you have”, “What you know” and “What you are”, totally ignore the most
relevant concept of “Who you know” – which is how humans establish trusted relationships.

Fundamental properties of identity

The unit relative-identity data –
1. must be unique (no two relative-identities should have the same identity data)
2. must be tamper-proof (difficult to reconstruct and reproduce)
3. must be secret - wholly / partially (should not be communicated in full form during the authentication; should be
known only to the related entities)
4. must be used simultaneously and uniquely, to identify all entities involved in the authentication transaction

Most of the prevalent conventional identity systems satisfy properties 1, 2 and 3 above. For example –
- Login/Password would satisfy 1, 2 (partially) and 3 (partially)
- Digital Certificates would satisfy 1, 2 and 3 (partially)

REL-ID: An Introduction 2
What is Mutual Authentication/Identification? Why does one need it?

Ask yourself the following questions –

- What is the meaning of authentication if it is not mutual?
- Why would I allow someone to authenticate me if I can’t authenticate him/her?
- Would I produce my passport to identify myself to someone who does not seemingly possess the requisite authority?
- Even so, don’t I run the risk of being duped into producing my passport to a person who looks authentically like
he/she has the requisite authority?

The basic flaw in identification over the internet is that an end-user assumes that the website challenging him/her for his/her
credentials is the authentic site – so long as interaction with the user-agent application (the web-browser) while accessing the
website, is identical to previous such interactions. That is to say – so long as the website looks the same, behaves the same,
and does not trigger a negative message from installed security products (due to more recent efforts in the anti-phishing
features of these products)

All things considered, are you sure you can trust such a website that asks for your login credentials?

Conclusion: Authentication, to be of any practical use, MUST BE MUTUAL

Fundamental properties of authentication / identification

The process for identification / authentication
1. must be tightly integrated with a given/underlying identity representation
2. must necessarily have a priori access to the identity data that is to be identified / authenticated
3. must necessarily authenticate all identifying / authenticating parties (entities) – preferably simultaneously

These are simple (minimal) properties that any identity / authentication system must possess. Some of them are straight
forward while some may not be seem obvious.

Let us now visit some of the prevalent identification / authentication processes in light of the above properties –
- Login/Password – satisfies 1 and 2 above
- Digital Certifications/SSL – does not satisfy 2 and 3, and hence, should NOT be used for authentication
- Hardware/Software Tokens (and OTPs) – satisfy 1 and 2 but do not satisfy 3

Please note that even the use of multi-factors satisfy only properties 1 and 2 and not the property 3

Let’s look at the third property above for authentication protocols that essentially says that the process MUST be mutual and
simultaneous. The term mutual has earlier been defined in the context of client-server architecture as “client must authenticate
the server and the server must authenticate the client” – essentially, classifying any two “1-way” authentication method as a
valid 2-WAY or mutual authentication process. The fundamental flaws in existing mutual and 1-Way authentication systems are
precisely due to the violation of properties (2) and (3) above.

Mutual authentication cannot and should not be implemented using two 1-WAY authentication schemes – e.g. 2-Way SSL, or a
combination of login/password and shared secrets/site-key. Any such scheme will be vulnerable to the same attacks that the 1-
WAY equivalent is vulnerable to.

How is Relative Identity different from other identity schemes?

Conventionally, identity is associated with the end-point entities (client or server) and authentication involved authenticating
the end-points. Authenticating this information for both end-points in sequence is NOT secure mutual authentication – it is a
concatenation of 2 instances of 1-WAY authentication.

The REL-ID (relative identity) approach to authentication is to identify and authenticate the ‘link/relationship’ between the end-
point entities – not the individual end-points. That is to say – IDENTITY must necessarily be associated with the ‘link’
representing the relationship between the end-points. This is the only representation, and authentication thereof, that can
legitimately be termed as MUTUAL – as the end-points are an integral part of the definition of any such representation.
REL-ID: An Introduction 3
Authenticating such a ‘link’ would necessarily be mutual – would ensure that all end-points are authenticated simultaneously,
and makes the identity of every end-point relative to the other end-point(s) axiomatically.

Conventional Identity System RELative-Identity based System

<ab> <ba>
<A::B>
A B A B
<A::B> = <ab>.<ba>
Login/Password Server- Certificate
Token Site-Key
Client Certificate

We believe that, in order to (a) represent the above information correctly at the end-points and (b) arrive at the correct
protocols for identification/authentication, one must develop the necessary mathematical frameworks and algorithms.
However, before starting to derive them, one must accept and acknowledge the fundamental paradigm shift in the desired
properties of such representations and algorithms.

The set of identity representations and identification / authentication algorithms constituting the REL-ID© Security Suite is one
such implementation of the identity paradigm described here. Assuming that authentication must necessarily be mutual and
simultaneous to be of any value, authentication schemes such as tokens, digital-certificates/SSL, login/password … cannot be
compared with REL-ID – since they offer only 1-WAY authentication, at best. Furthermore, methods/products that claim to
provide mutual authentication, but in reality implement two 1-WAY authentications (like SITE-KEY – flash-persistent object;
Shared Secrets …), will remain vulnerable to man-in-the-middle attacks due to the inherent vulnerability to the conventional
end-point identity representation scheme.

There are no known contemporary technologies/products that are built using mutual authentication protocols, which have
the properties mentioned in this article, and which are available commercially

TECHNOLOGIES, INC.
Start your relationship with us | www.rel-id.com | info@rel-id.com | US: +1 (813) 215-2069 | India: +91 (020) 27291882
COPYRIGHT © 2007-08 REL-ID Technologies, Inc. 062008
All rights reserved. No part of this work may be reproduced, stored in a retrieval system, adopted or transmitted in any form or by any means (electronic, mechanical, photographic,
graphic, optic recording or otherwise), translated in any language or computer language, without the prior written permission of REL-ID Technologies, Inc.
Due care has been taken to make this document as accurate as possible. However, REL-ID Technologies makes no representation or warranties with respect to the contents hereof and
shall not be responsible for any loss or damage caused to the user by the direct or indirect use of this document. Furthermore, REL-ID Technologies reserves the right to alter, modify or
otherwise change in any manner the content hereof, without obligation of REL-ID Technologies to notify any person of such revision or changes.
REL-ID, REL-ID Logo and REL-ID Tag Line are registered trademarks of REL-ID Technologies, Inc.

REL-ID: An Introduction 4