Upload
gertrude-norah-greer
View
230
Download
1
Tags:
Embed Size (px)
Citation preview
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
RespAuth Attack to shared RespAuth Attack to shared secretsecret
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
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
Access-Request (Request authenticator)
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
Access-Request (Request authenticator)
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
Diameter improvements at a Diameter improvements at a glance /2glance /2
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
Diameter improvements at a Diameter improvements at a glance /3glance /3
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