1 / 9

ENUM and Domainkeys as Distributed Identity Infrastructure

This proposal explores the idea of using the identity chain established by ENUM validation to convey E.164 identity to the internet, leveraging parts of ENUM and Domainkeys technology.

jcrown
Download Presentation

ENUM and Domainkeys as Distributed Identity Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ENUM and Domainkeysas Distributed Identity Infrastructure draft-mayrhofer-enum-domainkeys-00 Alexander Mayrhofer alexander.mayrhofer@enum.at 20.03.2006 draft-mayrhofer-enum-domainkeys

  2. Motivation • Identity is the NextGreatBuzz(tm) • A phone number is an identity • Most expensive part of ENUM provisioning: Validation • But: Validation takes the identity of the phone number to the ENUM domain • This identity an ENUM domain reflects – its most expensive component - is currently underused • So, let's make use of that! draft-mayrhofer-enum-domainkeys

  3. Leveraging identity – an idea +43 1 5056416 34 PSTN Identity transactions Bank Pizza Friends ENUM validation Internet Web sites Peers "Friends" 4.3.6.1.4.6.5.0.5.1.3.4.e164.arpa draft-mayrhofer-enum-domainkeys

  4. Idea / Proposal • Idea: Use the identity chain established by ENUM validation to convey the E.164 identity to the internet. • Proposal: Use parts of ENUM & Domainkeys technology • ENUM, but no full DDDS (just the domain) • Domainkeys, but just the key stuff/storage • = TXT record with public key in ENUM • ENUM domain owner = signer • Any internet user = verifier draft-mayrhofer-enum-domainkeys

  5. Example flow 4.3.6.1.4.6.5.0.5.1.3.4.e164.arpa ENUM Gateway 3 +43 1 5056416 34 Internet 4 Signed message 2 1 *man in the middle, Replay, etc. to be avoided by eg. Destination challenging sender … 1 – signing the message with private key 2 – transport of mesage to destination 3 – destination identifies E.164 number, fetches public key 4 – destination verfies signature If successful, destination can without prior knowledge assume that Sender is identical with number holder draft-mayrhofer-enum-domainkeys

  6. Features / why ENUM? • Available to any ENUM domain holder • (Note: that's the sales pitch part ;) • Receiving end requires no prior knowledge about sender • Any node on the internet can perform authentication • Domain internationally agreed • Common validation quality: • Number holder == ENUM domain owner draft-mayrhofer-enum-domainkeys

  7. Potential applications • Signing in to P2P networks • Especially when they deal with RTC – users "keep their number" – even on the P2P network • Without prior contact/knowledge • CLI signalling to the PSTN • Anonymous PSTN gateways can assure CLI on outbound calls without prior knowledge of the caller • SPIT prevention • Sender identification and whitelisting • More? draft-mayrhofer-enum-domainkeys

  8. More potential… • Even disconnected nodes could perform authentication, given that public key is cached (or the devices share a number) • PANs (the gadgets in my backpack to each other) • AdHoc (overlay?) networks with identical participants (gadgets in IETF shuttle busses? ;) • Handset to Base station draft-mayrhofer-enum-domainkeys

  9. Status • draft-mayrhofer-enum-domainkeys-00 • Contains idea without gritty details – to be fleshed out in upcoming versions • Few feedback received • Any opinions / feedback? • Volunteers for co-authors? • PKI/crypto knowledge required draft-mayrhofer-enum-domainkeys

More Related