Giuseppe Bianchi Hash/MD5 background; Message Authentication.

Giuseppe Bianchi

Hash/MD5 background;Hash/MD5 background;Message AuthenticationMessage Authentication

Giuseppe Bianchi

Hash FunctionHash Function

Any length message X

Fixed size digest Ye.g. 128 bits for MD5

Y = H(X)

Cannot be inverted, as not uniqueX = x bitsY = y bitsAssuming ideal mapping, Y is the result for 2x-y possible X messagesExample:

x=5 bits 32 messagesy=2 bits 4 digests32/4 = 8= 23

Giuseppe Bianchi

Properties of a good hash Properties of a good hash functionfunction

Preimage resistance (one way)Given Y = result of a hash, it is hard to find X such as

H(X)=YSecond preimage resistance (weak

collision resistance)Given X, it is hard to find another X’ such that

H(X) = H(X’)Collision resistance (strong collision

resistance)It is hard to find two generic X1 and X2 such that

H(X1) = H(X2)

Giuseppe Bianchi

Birthday paradoxBirthday paradox

1. What is the probability that none of you N=22 is born in my same day?

2. What is the probability that no two+ of us N=23 are born the same day?

%1.94365

364

365

11

2222

HHuman being X birthday

%3.49365

)!23365(/!365365

)22365()1365(365

365

221

365

21

365

111

23

23

!!

Giuseppe Bianchi

Birthday paradox againBirthday paradox again

Digest = D bitsNumber of messages = K

2

2

2

1

2

11

DK

DK

1. How many messages K to observe to get 50% probability to have my same digest?

2. How many messages K to observe to get 50% probability to have two same digest?

2/22177.1

2

1

2

)!2(/!2 DDKD

DD

KK

Giuseppe Bianchi

nknk

eee

eeee

n

i

n

k

nn

n

kn

n

n

n

n

n

knn

nknk

nknkkn

ik

i

ni

k

i

k

k

i

177.1)2log(2

2

1

11

12

11

1

)1(1)!(/!

2

)2log(2/2/

2/2/)1(1

1

/

1

1

22

2

1

1

Ricordando che per x piccolo1-x approx e^(-x)

Giuseppe Bianchi

Message digest sizeMessage digest sizeMust be considered against

birthday paradox!32 bits (RAND)

50% collision after 216 msg60.000 (very little!)

56 bits (DES)50% collision after 228 msg250M (still little!)

128 bits (MD5)50% collision after 264 msg1.8x1019 (OK!)

160 bits SHA-1

Giuseppe Bianchi

MD5 iterative constructionMD5 iterative construction

Merkle-Damgard approach

Message (any size)

Chunk (512 bits) Chunk (512 bits) Chunk (512 bits) Chunk (512 bits)

10000

Padding

LengthK mod 264

K bits

N x 512 bits

Initialization Vector(known)

F 128 bits F128 bits 128 bits F 128 bits F 128 bits

Hash

Compression function (if it is resistant, also iteration is)

Giuseppe Bianchi

Message authenticationMessage authentication

Sender Receiver

k kmessage m tag

Generate tag

messageK

tag

Generate tag

Generate tag

messageK

Verify Tag

=?

Giuseppe Bianchi

Requires secret key!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

Giuseppe Bianchi

Requires secret key!Requires secret key!

Pay 100 dollars Pay 1000 dollars

Pay 100 dollars Pay 1000 dollarsH(M,K) H(M,K)

Modified!And H(M’,K) not Computable by attacker

Secret key, so that attacker CANNOT recompute tag (not knowing K)

X Weaker than digital signature

Why? But fast, practical, and OK for two-party session Issues:

Must use good hash Must use shared secret among parties

Giuseppe Bianchi

SecuritySecurityAttacker is given a number of past

message/tag pairs(m1,t1), (m2,t2), (m3,t3), …Even more powerful: «chosen message» attack

Now sees message mMust NOT be able to forge tag t

Even more powerful: must NOT be able to forge ANY valid pair (m,t) for any chosen new msg

Formally: probability to forge valid pair must be NEGLIGIBLE

Giuseppe Bianchi

Short tags?Short tags?1 byte tagsNo way for attacker to guess tag

from msg, beyond pure random choice

Is this secure?

NO! Probability of guessing = 1/256Not nearly negligible!!

Note the crucial difference with encryption security definitions!

Giuseppe Bianchi

Message authentication Message authentication using hash functionsusing hash functions

Sender Receiver

k kmessage m tag

Hash function

messageK

tag

Generate tag

Hash function

messageK

Verify Tag

=?

Giuseppe Bianchi

Devil is in the details…Devil is 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?

Giuseppe Bianchi

Expansion attack!Expansion attack!

Trivial to “extend” the message!Especially critical if secret at the

beginningExample: start from MD5(k | x), k unknown secretAppend yTo 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

Giuseppe Bianchi

HMAC-MD5HMAC-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 neededipad = 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

Giuseppe Bianchi

Why HMAC?Why HMAC?quantitatively proven robustness: as

secure as its underlying hash issee Bellare, Canetti, Krawczyk, Keying Hash Functions for

Message AuthenticationActually more secure

Bellare 2006: collision resistence NOT necessaryNore strengthening neededPseudorandomness 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

Giuseppe Bianchi

Collisions without HMACCollisions without HMACCollision in hash = collision in

MACH(M,S) construction:

Obvious find collision on first part of the message, then

expandH(S,M) construction:

less obvious, but same problemStart from H(S,x) IVFind collision H*(IV,X1)=H*(IV,X2)Mi = x | pad(x) | Xi | pad (Xi)Hence H(S,M1)=H(S,M2)

Giuseppe Bianchi

Lecture 3.1:Lecture 3.1:

Handling Remote Access:Handling Remote Access:RADIUSRADIUS

Remote Authentication Dial In User ServiceRemote Authentication Dial In User Service

Recommended reading: RFC 2865, June 2000

Giuseppe Bianchi

MotivationMotivation

PPPPPP

NASNAS

Internet Service Internet Service ProviderProvider

Managing large-scale networks: a nightmareMultiple NAS, multiple access servicesNot only authentication, but also service-specific configuration assignment

Best achieved by managing single user "database"

User+passwd login

Giuseppe Bianchi

RADIUSRADIUSProvides 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, etcClient-Server protocol

NAS acts as RADIUS client1 primary server (0+ secondary servers - replicated)

Management of replicated servers implementation dependentServer may in turns act as a proxy

Based on UDP/IPServer port 1812 (client port ephemeral, as usual in C/S)

Giuseppe Bianchi

RADIUS architectureRADIUS architectureRADIUS Server applicationRegistered 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 serverAccounting Database

Whhen radius used for accountingFrequently used only for authentication

Giuseppe Bianchi

RADIUS Security featuresRADIUS Security featuresPer-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 networkPer-packet 16-bytes signature

Encrypted user password transmissionSame shared key used to transmit user passwordsRemaining information transmitted in clear text

Giuseppe Bianchi

PPPPPP

NASNAS

ISPISP

RADIUS scenarioRADIUS scenario

RADIUSRADIUSserverserver

1

2

1. User sends authentication attributes to NAS2. NAS wraps them into Access-Request sent to Server3. Server response: OK, NO, Challenge (for some AUTH)

if Y, user profile, authorization and config data added4. NAS notifies user

3

4

Access-Request

Response

Giuseppe Bianchi

Proxy OperationProxy Operation

ISPISP

RADIUSRADIUSserverserver

remoteremoteRADIUSRADIUSserverserver(or other AAA (or other AAA

e.g. Cisco e.g. Cisco TACACS+)TACACS+)

May be transparent or not transparent(e.g. change response to fit with local policies)

Frequently fromdifferent ISP:Typical Proxyusage isroaming

Giuseppe Bianchi

Message exchange Message exchange (example)(example)

If needed

Giuseppe Bianchi

packet formatpacket 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…

IP header UDP header RADIUS PACKET

code1 byte

identifier1 byte

length2 byte

authenticator16 byte

attributes***

Code (dec)

Packet

1 Access-Request

2 Access-Accept

3 Access-Reject

4 Accounting-Request

5 Accounting-Response

11 Access-Challenge

type len value type len value………

Giuseppe Bianchi

Packet authenticationPacket authenticationRequest Authenticator

In Access-Request (CS)16 randomly generated bytes

unpredictable and unique (over the lifetime of shared C/S secret)» To avoid replay attack

Response AuthenticatorIn Access-Accept/Reject/Challenge packets (SC)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)

Giuseppe Bianchi

Attributes (at a Attributes (at a glance)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: experimentalType 224-240: implementation-specific

Type 241-255: reserved Extensible Protocol

New attribute values can be added without disturbing existing implementations

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-Netmask10 Framed-Routing11 Filter-Id12 Framed-MTU13 Framed-Compression14-16 (for Login service)17 (unassigned)18 Reply-Message19 Callback-Number20 Callback-Id21 (unassigned)22 Framed-Route23 Framed-IPX-Network24 State25 Class26 Vendor-Specific27 Session-Timeout28 Idle-Timeout29 Termination-Action30 Called-Station-Id31 Calling-Station-Id32 NAS-Identifier33 Proxy-State34-36 (for LAT)37-39 (for AppleTalk)40-59 (res. for accounting)60 CHAP-Challenge61 NAS-Port-Type62 Port-Limit63 Login-LAT-Port

Giuseppe Bianchi

Access-RequestAccess-RequestTypically contains:

Who is the userUser-Name

» Mandatory: search key to access the user databasePassword

User-PasswordCHAP-password (when CHAP employed)

An identifier of the RADIUS clientNAS-IP or NAS-identifier

» user might access only a subset of NASAn 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

Giuseppe Bianchi

Password encryptionPassword encryption

Native User-Password

Step 1: padding to 16 bytes

u g o

u g o

Step 2: generate a 16 bytes hashusing key and the content of theauthenticator field of the request

MD5(secret | RequestAuth)

Step 3: XOR padded passwd & hash u g o

MD5(secret | RequestAuth)

If passwd longer than 16 characters:Step 4: compute MD5(secret | result of previous XOR) andStep 5: XOR with next segment of the passwd

Giuseppe Bianchi

Access-AcceptAccess-Accept

Login The user should be connected to a host. Framed A Framed Protocol should be started for the User, such as PPP or SLIP. Callback Login The user should be disconnected and called back, then connected to a host. Callback Framed The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP. Outbound The user should be granted access to outgoing devices. Administrative The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. NAS Prompt The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. Authenticate Only Only Authentication is requested, and no authorization information needs to be returned in the Access-Accept (typically used by proxy servers rather than the NAS itself).

Login The user should be connected to a host. Framed A Framed Protocol should be started for the User, such as PPP or SLIP. Callback Login The user should be disconnected and called back, then connected to a host. Callback Framed The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP. Outbound The user should be granted access to outgoing devices. Administrative The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. NAS Prompt The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. Authenticate Only Only Authentication is requested, and no authorization information needs to be returned in the Access-Accept (typically used by proxy servers rather than the NAS itself).

Possible values of the Service-Type option

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

Giuseppe Bianchi

Access-RejectAccess-Reject

Two main reasons:Authentication failed1+ attributes in the request were not

considered acceptable (authorization failed)

Giuseppe Bianchi

Access-ChallengeAccess-Challenge Used whenever the server wants/needs the user

to send a further responseE.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 userMay contain an explicit authentication challenge

NAS collects response from the user and sends a NEW Access-RequestNew IDNew User-Password - contains the user response (crypted)

Based on this, server accepts or rejects or send another challenge

Giuseppe Bianchi

PPP CHAP support with RADIUSPPP 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

Chap Response

Chap Success

Ver

ify

RADIUS Access Request (User Name, CHAP password, CHAP Challenge,Service :Framed PPP , …)

RADIUS Access Accept (Service : Framed PPP, …)

User NAS RADIUSSERVER

PPPPPP

CHAP RADIUS

UDP/IP

Giuseppe Bianchi

Lecture 3.2:Lecture 3.2:

RADIUS limits and RADIUS limits and extensionsextensions

Giuseppe Bianchi

RADIUS Security RADIUS Security WeaknessesWeaknesses

Recommended reading: Joshua Hill, “An analysis of the RADIUS Authentication Protocol”

Giuseppe Bianchi

Vulnerable to message sniffing Vulnerable to message sniffing and modificationand modification

Clear-text protocol privacy issuesUser-Name, Calling-Station-ID, NAS identification,

location attributes sent in the clear

Access-Request not authenticatedAttacker may intercept (e.g. MITM) an Access-

Request and change its contents effortlessAccess requests may be forged

Solution proposedMessage-Authenticator attributeTo be mandatorily used with EAP only, though

More later on EAP

Giuseppe Bianchi

Message-AuthenticatorMessage-AuthenticatorMessage signature

Primarily for Access-Request messagesSince they are not authenticatedOf course can be used also in Reject/Accept/Challenge

packetsMUST be used when EAP used with RADIUS (RFC 2869)

May (of course) be used with other authentication methodsUsual attribute syntax

Authenticator = HMAC-MD5(whole packet) =HMAC-MD5(type | ID | len | RequestAuth | attributes)

In computation, Authenticator = 0000.0000.0000.0000Shared secret used as key for the HMAC-MD5 hash

Type=80 Authenticator (16 bytes)Len=18

Giuseppe Bianchi

Attack to shared secret based Attack to shared secret based on User-Password attributeon User-Password attribute

Arbitrary User-ID

Arbitrary Password (< 16 bytes)

NASRADIUS server

Access-Request

User-Password attribute (16 bytes)Request Authenticator (16 bytes)XOR (password)

MD5(secret, RequestAuth)

Attack to the shared secret based on the User-Password attributeExhaustive search attackBut pre-computation of MD5 state not possible here, as

secret is first

Giuseppe Bianchi

Offline dictionary attacksOffline dictionary attacksTheir “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!

Giuseppe Bianchi

Attacking the password of a Attacking the password of a useruser

Victim User-ID

Arbitrary Password (< 16 bytes)

NASRADIUS server

Access-Request

User-Password attribute (16 bytes)XOR (password)

MD5(secret, RequestAuth)

FIRST STEP: as previous case, but with valid user ID:

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 reuseWorks only with 16 or less byte passwords (most cases)

New-passwords XOR MD5(secret, RequestAuth)

Spoofed Access-Request, with:

Giuseppe Bianchi

poor PRNG implementationspoor PRNG implementationsReplay AttacksReplay 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

Valid usersNAS

Access-Request (Request authenticator)

Access-Accept (Response authenticator)

Access-Request (ReqAuth in dictionary)

Access-Accept (corresponding RespAuth)

Dictionary of ReqAuth/RespAuth

Giuseppe Bianchi

poor PRNG implementationspoor PRNG implementationsAttack to Customer Attack to Customer

passwords /1passwords /1

Valid usersNAS


Dictionary of ReqAuth/User-Password

Passively monitor the network traffic allows to build a dictionary of Request Authenticators and the associated (protected) User-Password attributes

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

Giuseppe Bianchi

poor PRNG implementationspoor PRNG implementationsAttack to Customer Attack to Customer

passwords /2passwords /2

Arbitrary pwNAS


Dictionary of ReqAuth/User-Password

ACTIVELY submit known passwords to add known passwords to the dictionary of Request Authenticators and the associated (protected) User-Password attributes

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

Giuseppe Bianchi

Poor PRNG, a notePoor PRNG, a notePRNG cycle depends on underlying PRNG

seedN 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 numberGenerate 128 bit authenticator by appending 4 subsequent

32 bit random numbersCycle: reduced to 30 bits!!

Birthday attack: o(32000) packets!

Giuseppe Bianchi

Lessons learned from Lessons learned from RADIUSRADIUSDo-it-all-in-one does not pay off

AAA protocols should NOT implement their own security mechanismscarefully structured attacks break down RADIUS “simple” approachesMD5 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 layerRADSEC = Radius over TLS; RADIUS over IPsecDIAMETER approach: mandatory usage of IPsecEasy to say, much harder to deploy (complexity, cost, extra processing)

Mixing encryption with hashing may have severe side effect consequencesUsing MD5 hasing for password encryption was NOT a good idea –

see related attacksSingle (static) shared key: too risky

Require different shared keys per each client/server pairServer selects which shared secret to use: based on client IP address

Giuseppe Bianchi

AAA evolution:AAA evolution:beyond RADIUSbeyond RADIUS

Giuseppe Bianchi

RADIUS todayRADIUS todayRadius initially deployed to mainly support

dial-in PPP users and terminal login usersToday, RADIUS = de-facto standard for AAA

Universal support from device vendorsBut severe functional limits

Scalability: today much larger customer base “size”From a few thousands of users, as in first ISPsTo several M users as in cellular operators and national-level ISPs

Extensibility: new technologies

» Wireless, DSL, 3G, Ethernet, …many more service scenarios

» Mobile-IP, roaming, carrier-grade accounting, etc» new authentication mechanisms

Interoperability: lot left unspecified, and dealt with in proprietarilyE.g. failover, load balancing, server selection, etc

Giuseppe Bianchi

A note on scalabilityA note on scalability

What if 10.000 of such NAS? 400 access-requests/second

3.2 mbps server load if request averages 1KB Add 400 account-requests/second Add delivery of accounting records

Some RADIUS implementations may be unable to manage all this load with no packet loss!

Finally, add load peaks when NAS reboots (e.g. after power failure)

Many accounting records back-to-backRemote users log-in simultaneously

48 port NAS

Average session time = 20 minutes

In average 1 request every 25 sec

Conclusion: AAA servers (and their networks) may experience CONGESTION!!As well as packet drop!!

Giuseppe Bianchi

Ongoing evolution in IETFOngoing evolution in IETFDiameter

Started on dec 1998Now completed, activities moved to DiME (Diameter Maintenance

and Extensions WG)First WG email on jan 2006Planned actions: support of MIPv6; QoS; AAA in IP telephony

(SIP) and in Local Area Networks (VLAN)RADext

Started on august 2003RADIUS extensions with mandatory backward compatibility

Planned actions: AAA in IP telephony (SIP) and in Local Area Networks (VLAN), pre-paid support

No transport (still UDP) and Security enhancementsRADIUS/Diameter compatibility

Goal of both WGs!!

Giuseppe Bianchi

Why “duplicating” the work?Why “duplicating” the work? RADIUS:

Massive work on RADIUS deploymentDe-Facto standard, heavily integrated in business/ISP domains

Limitations can be circumvented with “small” ad-hoc extensions Diameter:

Brand new protocolThough somehow backward compatible, neverteless it changes lots

of basics» Transport, Packet format, philosophy, …

Much more powerfulbut also muuuuch more complex

Perfect choice in new (emerging) scenariosMost notably 3G mobility world

Uncertainty on what will be THE future AAA protocol, and IF there will be ONE dominant protocol: keep both!

Giuseppe Bianchi

Diameter: whole pictureDiameter: whole picture

DIAMETER applications(inherit base protocol and extend/customize it for specific purposes)

Diameter Mobile IPv4 app

RFC 4004

Diameter NAS appRFC 4005

Diameter Credit ctrl app

RFC 4006

Diameter EAP app

RFC 4072

Diameter SIP app

in RFC queue

DIAMETERBase protocol

RFC 3588

AAA Transport Profile (SCTP/TCP-based) – RFC 3539

A very complex specification! Indeed, DIAMETER = 2 x RADIUS We will NOT enter into ANY detail…

Giuseppe Bianchi

Diameter improvements at a Diameter improvements at a glance /1glance /1

reliable transport» Versus RADIUS unreliable UDP and “proprietary” retransmission

Reliability essential in accountingPacket loss = money loss!

SCTP preferred (otherwise TCP)One persistent connection between client & serverPackets pipelined in this single connection

Standardized error and fail-over control» Versus RADIUS implementation dependent approaches

Error control and retransmission functionalities at the application levelDuplicate detection

Especially important in accountingApplication-layer watchdog: periodic packets devised to understand when

Diameter peer failsDefault: 1 message every 30 +/- 2 seconds (artificial random jitter

added to avoid syncronized arrivals)May be decreased to 6 +/-2 secondsTimer reset when other packets arrive (i.e. watchdogs used only

when no other packets arrive)

Giuseppe Bianchi


Extension of functional limits 24 bit AVP filed (Attribute-Value-Pair) versus 8 bit attribute field (exhausted) No more 8 bit ID (limits to 256 packets on the fly from client to same server – not

scalable), but 32 bit (Hop-by-Hop identifier) Duplicate detection (E2E identifier and T flag) Capability negotiation: mandatory/non-mandatory AVPs (flag M) allow to restrict

reject only to serious lack of capabilities» Versus radius “reject” answer if request attributes not supported

Version: 0x01R P E T

Message length (3B)res-flags Command-Code (3B)

Application-ID (4B)Hop-By-Hop Identifier (4B)End-To-End Identifier (4B)

AVP code (4B)V M P res-flags AVP length (3B)

Vendor-ID (optional, 4B)

…… DATA ……

AVPs

Diameter headerFlags:R: 1=request, 0=answerP: proxiableE: this is an error messageT: potentially retransmitted message

Flags:V: vendor-specific bit: vendor ID follows, code is from vendorM: mandatory bit: reject if this AVP unsupportedP: privacy bit: need for e2e encryprion

Giuseppe Bianchi


Peer discovery, configuration, capability detection

» In RADIUS, clients are manually configuredDiameter uses specific IETF protocols

(Service Location Protocol version 2)C/S exchange capabilities when they set-up a transport connection

Identity, diameter version, security mechanisms, supported Diameter applications

Supports unsolicited SC messages» Versus RADIUS pure client-server paradigm

Allows unsolicited abort/disconnect, reauthentication/reauthorization,… Very detailed management of intermediate

entities» Versus sloppy specification in (early) RADIUS

Clear distinction between hop-by-hop and end-to-endEnd-To-End protection mechanisms

» RADIUS can only deal with Hop-by-HopExplicit specification of Proxies, Redirects, Relay agents

Roaming supportRouting (!!) support

Giuseppe Bianchi

Diameter agents operationDiameter agents operation

request

answerNo intermediate agent

request

answer

Relay agent: accept requestand routes it to the proper server based on info containedIn the message (destination realm)

Proxy agent: as relay but modifies message (hence e2e message authentication broken)

Relayagent

request

answer

[email protected]. realm

Realm routing table

request

answerRelayagent

request

answer

redirectagent

req Redirect notif.

Realm routing tableRedirect agent: provide routingdecision on incoming requestbut does not actually route request (returns redirect)

Useful when Diameter routing decisions are centralized (e.g. for a consortium of realms)Typical usage: individual relays default-route to redirect agent

Giuseppe Bianchi Hash/MD5 background; Message Authentication.

Documents

Transcript of Giuseppe Bianchi Hash/MD5 background; Message Authentication.