Eap potp
This presentation is the property of its rightful owner.
Sponsored Links
1 / 9

EAP-POTP PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on
  • Presentation posted in: General

EAP-POTP. Magnus Nyström, RSA Security 23 May 2005. Overview. EAP-POTP Enables programmatic use of a connected OTP token Provides mutual authentication Generates keying material Does not rely on tunnelling (provides privacy for OTP values) Enables fast session resumption EAP-POTP

Download Presentation

EAP-POTP

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Eap potp

EAP-POTP

Magnus Nyström, RSA Security

23 May 2005


Overview

Overview

  • EAP-POTP

    • Enables programmatic use of a connected OTP token

    • Provides mutual authentication

    • Generates keying material

    • Does not rely on tunnelling (provides privacy for OTP values)

    • Enables fast session resumption

  • EAP-POTP

    • Complements EAP-PEAP, EAP-TTLS, and EAP-FAST

    • May be used as a better alternative for an “inner” EAP method than EAP-GTC, PAP, CHAP, etc


Characteristics

Characteristics

  • Built on the principle of TLVs

    • 13 TLVs defined: Version, Server-Info, Resume, OTP, Confirm, Vendor-Specific, Counter, Time Stamp, Keep Alive, Token Serial, User Identifier, NAK, New PIN

    • Keep-Alive added in draft 2, needed to protect against time-outs (sent e.g. by peer when waiting for user input)

  • The method is profiled for RSA SecurID – EAP-POTP RSA SecurID

    • Profiles for other OTP algorithms expected and desired

    • May be used as a framework within a framework

      • EAP is framework for many authentication mechanisms

      • POTP is framework for OTP-based mechanisms within EAP


Principles of operation

EAP-Request/Identity

EAP-Response/Identity

Radius-Access-Request

Radius-Access-Challenge

EAP-Request/OTP

Server Info TLV

OTP TLV

EAP-Response/OTP

User Identifier TLV

OTP TLV

Radius-Access-Request

Radius-Access-Challenge

Principles of Operation

EAP

RADIUS

Calculate keys,

Calculate MAC

Calculate keys,

Verify MAC,

Calculate new

MAC


Principles of operation continued

EAP-Request/OTP

Confirm TLV

EAP-Response/OTP

Confirm TLV

Radius-Access-Request

Radius-Access-Accept

EAP-Success

Start of encrypted and mutually

authenticated session

Principles of Operation, Continued

EAP

RADIUS

Verify MAC


Key derivation

Key derivation

  • Both sides calculate:

    KMAC | KENC | MSK | EMSK =

    PBKDF2-SHA256 (otp, salt | pepper | auth_addr, iteration_count, kLen)

    • KMAC is used to authenticate (MAC) the parties – MACs on PDUs

    • KENC is used to protect sensitive data

    • MSK is delivered to the EAP method caller (“Master Session Key”)

    • EMSK is saved for future use

    • PBKDF2 is defined in PKCS #5 v2.0 (Password-based KDF)

    • otp is the OTP value

    • salt and pepper are random nonces (only salt is sent in protocol)

    • auth_addr is the NAS address as seen by the peer

    • iteration_count slows down an attacker (as does pepper), and

    • kLen = | KMAC | + | KENC | + | MSK | + | EMSK |


Authentication

Authentication

  • Use KMAC to calculate MACs:

    • Peer calculates MAC on all received and sent EAP messages

    • EAP Server verifies client MAC and then calculates MAC on peer’s message

  • Change since draft 2: EAP headers (EAP Code, Identifier, and Length) not included in MAC

    • This is due to implementation experience, Identifier values not always known by sender


For discussion

For discussion

  • Need to identify accepted New PIN

    • New flag in OTP TLV suggested (informs peer that PIN was accepted and shall be used in new OTP calculations)

  • Calculation of keys also in unprotected mode?

  • Profiles for other OTPs?


Next steps

Next steps

  • Agreement and stabilization of document content

  • Publication of draft 3 (IETF I-D -02)

    • Ask for IETF last-call subsequent to that?


  • Login