T-110.557 Research Seminar on Telecommunications Software Integrating Legacy User Authentication with HIP Jani Hautakorpi (Jani.Hautakorpi@hut.fi) 1 / 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 2 / 11
HIP Base Exchange Initiator Responder I1 : trigger exchange select pre-computed R1 R1 : puzzle, D-H, key, sig check sig remain stateless solve puzzle I2 : solution, D-H, {key}, sig check cookie compute D-H check puzzle check sig R2 : sig check sig compute D-H 3 / 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 4 / 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 5 / 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 6 / 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 7 / 11
Authentication Proposal for HIP (2/3) Initiator Responder I1 : challenge/response trigger prepare challenge R1 : convey challenge optional RADI- nonce, token challenge US/DIAMETER prepare response I2 : convey response username, H(username, password, token response, nonce, I's HIT, R's HIT) check response after HIP related checks R2 : convey result boolean result code optional RADI- US/DIAMETER check result 8 / 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 9 / 11
Real-life Scenario 1. DNS ● Resilient to the attacks query / Client Compromised response that has been directed [initiator] DNS server toward DNS ● Attacker has hacked a 2. HIP with legacy aut- DNS server hentication – HI, HIT and IP of the real server has been Real server [responder] changed Fake server [attacker] service ● Attacker cannot get user's credentials 10 / 11
Questions, comments? 11 / 11
Recommend
More recommend
