Integrating Legacy User Authentication with HIP Jani Hautakorpi - - PowerPoint PPT Presentation

1 / 11

T-110.557 Research Seminar on Telecommunications Software

Integrating Legacy User Authentication with HIP

Jani Hautakorpi (Jani.Hautakorpi@hut.fi)

2 / 11

Contents

• HIP base exchange
• Selected legacy user authentication mechanisms:

– Digest Access Authentication – EAP (Extended Authentication Protocol) – XAuth (Extended Authentication within IKE)

• Proposal on how to integrate legacy user

authentication with HIP

• Real-life scenario

3 / 11

HIP Base Exchange

select pre-computed R1 remain stateless check cookie check puzzle check sig compute D-H check sig solve puzzle compute D-H check sig Initiator Responder I1: trigger exchange R1: puzzle, D-H, key, sig I2: solution, D-H, {key}, sig R2: sig

4 / 11

Digest Access Authentication

• Originally developed for HTTP
• Currently used e.g. with SIP
• Uses challenge/response paradigm:

– Challenge: nonce value (hexadesimal data) – Response: checksum from username, password,

requested URI, ...

• Verifies that both parties know the shared secret
• Text-based mechanism

5 / 11

EAP

• Originally designed for environment, where IP

connectivity was not available

• Today, used also on top of UDP and TCP
• Uses challenge/response paradigm
• Defines e.g. terms: backend authentication server,

EAP server and pass-through agent

• Supports many authentication mechanisms
• EAP can be encapsulated either to RADIUS or to

DIAMETER packets

6 / 11

XAuth

• Was an attempt to provide legacy user

authentication within IKE

• Just an extension to IKE, didn't affect to IKE

itself

• Uses secure ISAKMP messages, so transmitted

credential are encrypted

• ISAKMP is a binary protocol
• Ability to periodically authenticate users

7 / 11

Authentication Proposal for HIP (1/3)

• At the present, HIP authenticates only host
• Some fundamental ideas behind the proposal:

– HIP's puzzle mechanism must be preserved – Users could be logically bound to SAs – Design should be as simple as possible – Adequate level of security for most use cases – Mechanism should be effective (RTT- & time-wise)

• Proposal is a high-level proposal, no bit-level

issues discussed

8 / 11

Authentication Proposal for HIP (2/3)

prepare challenge check response after HIP related checks prepare response check result Initiator Responder I1: challenge/response trigger R1: convey challenge I2: convey response R2: convey result

• ptional RADI-

US/DIAMETER

• ptional RADI-

US/DIAMETER nonce, token challenge username, H(username, password, token response, nonce, I's HIT, R's HIT) boolean result code

9 / 11

Authentication Proposal for HIP (3/3)

• Key features:

– Incorporated to HIP base exchange – Uses challenge/response mechanism – Only two-factor authentication allowed – Possibility to use backend authentication servers – Approximately host-wide ACLs can be deployed – Reliable log data can be produced – User authentication does not use asymmetric

cryptography

10 / 11

Real-life Scenario

• Resilient to the attacks

that has been directed toward DNS

• Attacker has hacked a

DNS server

– HI, HIT and IP of the

real server has been changed

• Attacker cannot get

user's credentials

Client [initiator] Real server [responder]

• 2. HIP with

legacy aut- hentication service Fake server [attacker] Compromised DNS server

• 1. DNS

query / response

11 / 11

Questions, comments?