Hash /MD5 background; Message Authentication

1. Hash/MD5 background;Message Authentication

2. Hash Function Any length message X Y = H(X) Fixed size digest Y e.g. 128 bits for MD5 Cannot be inverted, as not unique X = x bits Y = y bits Assuming ideal mapping, Y is the result for 2x-y possible X messages Example: x=5 bits  32 messages y=2 bits  4 digests 32/4 = 8= 23

3. Properties of a good hash function • Preimageresistance (one way) • Given Y = resultof a hash, itis hard tofind X suchas H(X)=Y • Secondpreimageresistance (weakcollisionresistance) • Given X, itis hard tofindanother X’ suchthatH(X) = H(X’) • Collisionresistance (strong collisionresistance) • Itis hard tofindtwogeneric X1 and X2 suchthatH(X1) = H(X2)

4. Birthday paradox H Human being X  birthday • What is the probability that none of you N=22 is born in my same day? • What is the probability that no two+ of us N=23 are born the same day? !!

5. Birthday paradox again • Digest = D bits • Number of messages = K How many messages K to observe to get 50% probability to have my same digest? How many messages K to observe to get 50% probability to have two same digest?

6. Ricordando che per x piccolo 1-x approx e^(-x)

7. Message digest size • Must be considered against birthday paradox! • 32 bits (RAND) • 50% collision after 216 msg • 60.000 (very little!) • 56 bits (DES) • 50% collision after 228 msg • 250M (still little!) • 128 bits (MD5) • 50% collision after 264 msg • 1.8x1019 (OK!) • 160 bits SHA-1

8. MD5 iterative construction • Merkle-Damgard approach LengthK mod 264 K bits Padding Message (any size) 10000 N x 512 bits Chunk (512 bits) Chunk (512 bits) Chunk (512 bits) Chunk (512 bits) F F F F 128 bits 128 bits 128 bits 128 bits 128 bits Initialization Vector (known) Hash Compression function (if it is resistant, also iteration is)

9. Message authentication k k message m tag Sender Receiver Generate tag Verify Tag K message K message Generate tag Generate tag tag =?

10. Requires secret key! message m CRC(m) message m* CRC(m*) CRC meant to DETECT random errors! Not meant to prevent attacks! Attacker can trivially recompute «valid» CRC

11. Requires secret key! Secret key, so that attacker CANNOT recompute tag (not knowing K) Pay 100 dollars Pay 1000 dollars X Pay 100 dollars H(M,K) Pay 1000 dollars H(M,K) Modified! And H(M’,K) not Computable by attacker • Weakerthandigitalsignature • Why?  • But fast, practical, and OK for two-party session • Issues: • Must use goodhash • Must use shared secret among parties

12. Security • Attackerisgiven a number of pastmessage/tagpairs • (m1,t1), (m2,t2), (m3,t3), … • Even more powerful: «chosenmessage» attack • Nowseesmessage m • Must NOT be able to forge tag t • Even more powerful: must NOT be able to forge ANY validpair (m,t) for anychosennew msg • Formally: probability to forge validpair must be NEGLIGIBLE

13. Short tags? • 1 byte tags • No way for attacker to guesstag from msg, beyond pure random choice • Isthissecure? • NO! Probability of guessing = 1/256 • Notnearlynegligible!! • Note the crucialdifference with encryption security definitions!

14. Message authenticationusinghashfunctions k k message m tag Sender Receiver Generate tag Verify Tag K message K message Hash function Hash function tag =?

15. Devilis in the details… • So far so good. But… • How to combine message and K? • tag = ? • Hash(message, K)? • Hash(K,message)? • Who matters? Shouldn’t this be the same?

16. Expansion attack! • Trivial to “extend” the message! • Especially critical if secret at the beginning • Example: start from MD5(k | x), k unknown secret • Append y • To compute MD5(k | x | y) use iterative Merkle construction! • No need to know k!!! • Length (Damgard) strengthening: helps but does not solve the problem • A strong reason to use different constructs (HMAC) • http://csrc.nist.gov/pki/HashWorkshop/2005/Nov1_Presentations/Puniya_hashDesign.pdf

17. HMAC-MD5 HMACK(M) = H(K+XOR opad || H(K+XOR ipad || M)) • K+ = shared key padded to hash basic block size • When H=MD5, padding to 512 bits • opad = 0x36 = 00110110 repeated as needed • ipad = 0x5C = 01011100 repeated as needed • Why HMAC and not just a Hash? • Hash H: applies to known message; does not assume any secret key • Including secret key in Hash: • At 1996: many naive approaches • e.g. secret as IV, or secret in the message as Radius Response Authenticator  • But none was backed-up by theoretical results

18. Why HMAC? • quantitatively proven robustness: as secure as its underlying hash is • see Bellare, Canetti, Krawczyk, Keying Hash Functions for Message Authentication • Actually more secure • Bellare 2006: collision resistence NOT necessary • Nore strengthening needed • Pseudorandomness only requirement • You can use HMAC with MD5 or SHA-1 even if there are algorithms to compute collision • Practical and flexible (you may change the underying hash with more robust one) • Efficient computation

19. Collisionswithout HMAC • Collision in hash = collision in MAC • H(M,S) construction: • Obvious • findcollision on first part of the message, thenexpand • H(S,M) construction: • lessobvious, butsameproblem • Start from H(S,x)  IV • FindcollisionH*(IV,X1)=H*(IV,X2) • Mi = x | pad(x) | Xi | pad (Xi) • Hence H(S,M1)=H(S,M2)

20. Lecture 3.1:Handling Remote Access:RADIUSRemote Authentication Dial In User Service Recommended reading: RFC 2865, June 2000

21. Motivation • Managing large-scale networks: a nightmare • Multiple NAS, multiple access services • Not only authentication, but also service-specific configuration assignment • Best achieved by managing single user "database" User+passwd login Internet Service Provider NAS PPP

22. RADIUS • Provides centralized AAA functionalities • Authentication • are you really the one you claim to be? • Authorization • Do you have permissions to access a service? • Accounting • what are you currently doing/using/paying? • Transmitted bytes, billing, etc • Client-Server protocol • NAS acts as RADIUS client • 1 primary server (0+ secondary servers - replicated) • Management of replicated servers  implementation dependent • Server may in turns act as a proxy • Based on UDP/IP • Server port 1812 (client port ephemeral, as usual in C/S)

23. RADIUS architecture • RADIUS Server application • Registered User Database • For each entry (user_name), contains (at least): • Authentication information (secrets) • Authentication Method • One per user! Otherwise attacker would negotiate the least secure method from among a set • If multiple authentication methods provided, much better use distinct user names! • Authorization attributes (access profile per each user) • Client database • Clients which are entitled to communicate with the server • Accounting Database • Whhen radius used for accounting • Frequently used only for authentication

24. RADIUS Security features • Per-packet authenticated reply • Transactions are authenticated through the use of a shared key between RADIUS server and RADIUS clients • Well, not all the transaction but only the reply packet: more later • Shared Key never sent over the network • Per-packet 16-bytes signature • Encrypted user password transmission • Same shared key used to transmit user passwords • Remaining information transmitted in clear text

25. RADIUS scenario • User sends authentication attributes to NAS • NAS wraps them into Access-Request sent to Server • Server response: OK, NO, Challenge (for some AUTH)if Y, user profile, authorization and config data added • NAS notifies user RADIUSserver ISP Access-Request 2 3 NAS Response 1 PPP 4

26. Proxy Operation RADIUSserver May be transparent or not transparent (e.g. change response to fit with local policies) remoteRADIUSserver (or other AAA e.g. Cisco TACACS+) ISP Frequently fromdifferent ISP: Typical Proxyusage is roaming

27. Message exchange (example) If needed

28. packet format • Code: type of radius packet • Identifier: match requests with responses • IP src and UDP src also help matching • Length • minimum 20, maximum 4096 • Authenticator: • used to authenticate reply from server • Used in user password-hiding algorithm • Attributes: extensible information field • Turned out not being extensible enough with “only” 256 types… ……… type len value type len value code 1 byte identifier 1 byte length 2 byte authenticator 16 byte attributes *** IP header UDP header RADIUS PACKET

29. Packet authentication • Request Authenticator • In Access-Request (CS) • 16 randomly generated bytes • unpredictable and unique (over the lifetime of shared C/S secret) • To avoid replay attack • Response Authenticator • In Access-Accept/Reject/Challenge packets (SC) • One-way MD5 hash of • the request authenticator, • the shared secret, • the packet response information • Response packet is signed! Otherwise packet tampering possible! • Specifically:MD5(Code | ID | Length | RequestAuth | Attributes | Secret)

30. 1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 13 Framed-Compression 14-16 (for Login service) 17 (unassigned) 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 (unassigned) 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id 32 NAS-Identifier 33 Proxy-State 34-36 (for LAT) 37-39 (for AppleTalk) 40-59 (res. for accounting) 60 CHAP-Challenge 61 NAS-Port-Type 62 Port-Limit 63 Login-LAT-Port Attributes (at a glance) • Information and configuration details • carried by request and/or reply (accept/reject/challenge) packets • Any number of attributes in a packet • Length field  end of attributes payload • Order of attributes does NOT matter • Some attributes may be included more than once • effect is attribute-specific (here order may matter!) • Up to 28 attributes (1 byte type field): • Type 0: reserved • Type 1-191: IANA (public) assigned/assignable • Type 192-240: for private use • Type 192-223: experimental • Type 224-240: implementation-specific • Type 241-255: reserved • Extensible Protocol • New attribute values can be added without disturbing existing implementations

31. Access-Request • Typically contains: • Who is the user • User-Name • Mandatory: search key to access the user database • Password • User-Password • CHAP-password (when CHAP employed) • An identifier of the RADIUS client • NAS-IP or NAS-identifier • user might access only a subset of NAS • An identifier of the port the user is accessing • NAS-Port (if the NAS has ports) • Wi-Fi: Logical association • Dial Up: physical (modem) port# receiving the user call • User might be restricted to access only specific ports

32. Password encryption Native User-Password u g o Step 1: padding to 16 bytes u g o Step 2: generate a 16 bytes hashusing key and the content of theauthenticator field of the request MD5(secret | RequestAuth) u g o Step 3: XOR padded passwd & hash MD5(secret | RequestAuth) If passwd longer than 16 characters: Step 4: compute MD5(secret | result of previous XOR) and Step 5: XOR with next segment of the passwd

33. Access-Accept • Positive server response • User authentication credentials OK • Contains all the service-specific configuration • Including the Service-Type attribute • Complemented with other service-related configuration parameters • E.g. IP address, mask, etc Possible values of the Service-Type option

34. Access-Reject • Two main reasons: • Authentication failed • 1+ attributes in the request were not considered acceptable (authorization failed)

35. Access-Challenge • Used whenever the server wants/needs the user to send a further response • E.g. a challenge/response authentication mechanisms • Not necessarily CHAP (see CHAP support later on)! Could be RADIUS support for GSM/UMTS authentication! • E.g. prompting the user to enter a password • Challenge typically contains • One or more reply-message attributes • Which MAY be used in a very flexible manner • May contain text to be prompted to the user • May contain an explicit authentication challenge • NAS collects response from the user and sends a NEW Access-Request • New ID • New User-Password - contains the user response (crypted) • Based on this, server accepts or rejects or send another challenge

36. PPP CHAP support with RADIUS • CHAP challenge locally generated by NAS • No need to know user password for this! • CHAP challenge + response sent to RADIUS server • RADIUS server retrieves user password from database, computes and compares CHAP response Chap Challenge RADIUS Access Request (User Name, CHAP password, CHAP Challenge, Service :Framed PPP , …) Chap Response Verify RADIUS Access Accept (Service : Framed PPP, …) Chap Success CHAP RADIUS UDP/IP PPP PPP User NAS RADIUS SERVER

37. Lecture 3.2:RADIUS limits and extensions

38. RADIUS Security Weaknesses Recommended reading: Joshua Hill, “An analysis of the RADIUS Authentication Protocol”

39. Vulnerable to message sniffing and modification • Clear-text protocol  privacy issues • User-Name, Calling-Station-ID, NAS identification, location attributes sent in the clear • Access-Request not authenticated • Attacker may intercept (e.g. MITM) an Access-Request and change its contents effortless • Access requests may be forged • Solution proposed • Message-Authenticator attribute • To be mandatorily used with EAP only, though • More later on EAP

40. Message-Authenticator • Message signature • Primarily for Access-Request messages • Since they are not authenticated • Of course can be used also in Reject/Accept/Challenge packets • MUST be used when EAP used with RADIUS (RFC 2869) • May (of course) be used with other authentication methods • Usual attribute syntax • Authenticator = HMAC-MD5(whole packet) =HMAC-MD5(type | ID | len | RequestAuth | attributes) • In computation, Authenticator = 0000.0000.0000.0000 • Shared secret used as key for the HMAC-MD5 hash Type=80 Len=18 Authenticator (16 bytes)

41. RespAuth Attack to shared secret • Attack to the shared secret based on the Response Authenticator • RespAuth = MD5(Code | ID | Length | RequestAuth | Attributes | Secret) • Secret placed at the end: very bad idea!! • Pre-computation of MD5 state for (Code | ID | Length | RequestAuth | Attributes) reduces the computational requirement for a successful offline exhaustive search attack

42. Attack to shared secret based on User-Password attribute RADIUS server • Attack to the shared secret based on the User-Password attribute • Exhaustive search attack • But pre-computation of MD5 state not possible here, as secret is first NAS Access-Request Arbitrary User-ID Arbitrary Password (< 16 bytes) User-Password attribute (16 bytes) Request Authenticator (16 bytes) XOR (password) MD5(secret, RequestAuth)

43. Offline dictionary attacks • Their “effectiveness” depends on chosen secret • (Often ignored) advice from RFC 2865: • “The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged.” • Many implementations only allow shared-secrets that are ASCII characters, and less than 16 characters; • resulting RADIUS shared secrets are low entropy!

44. Attacking the password of a user FIRST STEP: as previous case, but with valid user ID: RADIUS server NAS Access-Request Victim User-ID Arbitrary Password (< 16 bytes) User-Password attribute (16 bytes) XOR (password) MD5(secret, RequestAuth) SECOND STEP: Attacker now able to “encrypt” the user password!! May exploit: 1) lack of upper limit on authentication rate at server-side (limits imposed on clients are by-passed) 2) RADIUS servers typically do not check for authenticator reuse Works only with 16 or less byte passwords (most cases) Spoofed Access-Request, with: New-passwords XOR MD5(secret, RequestAuth)

45. poor PRNG implementationsReplay Attacks • Security of radius depends on the uniqueness and non-predictable generation of the Request Authenticator • Some implementations exploit poor Pseudo-Random Number Generators (PRNGs) • Short cycles, predictable • Immediate exploitation: replay attack:authenticate/authorize an illegal user with no valid password NAS Access-Request (Request authenticator) Valid users Access-Accept (Response authenticator) Dictionary of ReqAuth/RespAuth Access-Request (ReqAuth in dictionary) Access-Accept (corresponding RespAuth)

46. poor PRNG implementationsAttack to Customer passwords /1 • Repeated Request Authenticator observed • XOR previous user-password with new user-password • From different users • Result: since ReqAuth is the same • (user-password #1) XOR (user-Password #2) == [pw_user1 XOR MD5(secret,ReqAuth)] XOR [ps_user2 XOR MD5(secret,ReqAuth)] == pw_user1 XOR pw_user2 • BUT passwords from different users differ in length: • last characters of longer password are put in clear!! • Password sizes are known!! • Now intelligent dictionary attack (guided by improper habits to select passwords with low entropy) may clear passwords Passively monitor the network traffic allows to build a dictionary of Request Authenticators and the associated (protected) User-Password attributes NAS Access-Request (Request authenticator) Valid users Dictionary of ReqAuth/User-Password

47. poor PRNG implementationsAttack to Customer passwords /2 • If customer Access-Request uses a Request Authenticator already in the dictionary linked to a KNOWN password, customer password gets known! • Since ReqAuth is the same • (User-password from customer) XOR (user-Password from attacker) == [pw_user XOR MD5(secret,ReqAuth)] XOR [known_pw XOR MD5(secret,ReqAuth)] == pw_user XOR known_pw  pw_user in clear ACTIVELY submit known passwords to add known passwords to the dictionary of Request Authenticators and the associated (protected) User-Password attributes NAS Access-Request (Request authenticator) Arbitrary pw Dictionary of ReqAuth/User-Password

48. Poor PRNG, a note • PRNG cycle depends on underlying PRNG seed • N bit seed  only 2^N different values! • Birthday attack: ½ prob with approx 2N/2 • N=16  birthday attack with o(250) packets! • C drand48  birthday attack with o(16M) packets • (not really a lot!) • Terrific (?) implementation idea: • Start from 32 bit random number • Generate 128 bit authenticator by appending 4 subsequent 32 bit random numbers • Cycle: reduced to 30 bits!! • Birthday attack: o(32000) packets!

49. Lessons learned from RADIUS • Do-it-all-in-one does not pay off • AAA protocols should NOT implement their own security mechanisms • carefully structured attacks break down RADIUS “simple” approaches • MD5 serious flaws emerged recently (2005, Wang and Yu) • MD5 hard to upgrade in radius (requires complete change) • all the RADIUS security architecture will now vanish? • Current trend: rely on an underlying security layer • RADSEC = Radius over TLS; RADIUS over IPsec • DIAMETER approach: mandatory usage of IPsec • Easy to say, much harder to deploy (complexity, cost, extra processing) • Mixing encryption with hashing may have severe side effect consequences • Using MD5 hasing for password encryption was NOT a good idea – see related attacks • Single (static) shared key: too risky • Require different shared keys per each client/server pair • Server selects which shared secret to use: based on client IP address

50. AAA evolution:beyond RADIUS