In dit document worden twee RADIUS-beveiligingsmechanismen beschreven:
Dit document beschrijft wat deze beveiligingsmechanismen zijn, hoe ze worden gebruikt en wanneer u een validatiestoornis zou moeten verwachten.
Per RFC 2865 is de header van de verificator 16 bytes lang. Wanneer het in een Toegang-Verzoek wordt gebruikt, wordt het genoemd een Authenticator van het Verzoek. Wanneer het gebruikt wordt in elke vorm van respons, wordt het een Response Authenticator genoemd. Het wordt gebruikt voor:
Als de server reageert met de juiste Response Authenticator, kan de client berekenen als die respons gerelateerd was aan een geldig verzoek.
De client stuurt het verzoek door de willekeurige verificatieheader. Vervolgens berekent de server die de respons verstuurt de Response Authenticator met het gebruik van het verzoekpakket samen met het gedeelde geheim:
ResponseAuth = MD5(Code + ID + Length + RequestAuth + Attributes + Secret)
De client die de reactie ontvangt, voert dezelfde handeling uit. Als het resultaat hetzelfde is, klopt het pakje.
Validering treedt op als de switch het verzoek niet meer in het geheugen stelt (bijvoorbeeld vanwege de onderbreking). U zou het ook kunnen ervaren wanneer het gedeelde geheim ongeldig is (ja - Access-Afwijzen omvat ook deze header). Op deze manier kan het Network Access Apparaat (NAD) de gedeelde geheime tegenstrijdigheid detecteren. Meestal wordt dit door AAA-klanten/servers (Verificatie, autorisatie en accounting) gemeld als een gedeelde belangrijke mismatch, maar de details worden niet onthuld.
De header van de verificator wordt ook gebruikt om te voorkomen dat de gebruiker-Wachtwoord in onbewerkte tekst wordt verzonden. Eerst wordt het bericht Grootte 5 (MD5 - geheim, authentiek) berekend. Vervolgens worden verscheidene XOR - transacties met de aantekeningen van het wachtwoord uitgevoerd. Deze methode is gevoelig voor offline aanvallen (regenboogtabellen) omdat MD5 niet meer gezien wordt als een sterk algoritme in één richting.
Dit is het Python-script dat het User-Password compileert:
def Encrypt_Pass(password, authenticator, secret):
m = md5()
m.update(secret+authenticator)
return "".join(chr(ord(x) ^ ord(y)) for x, y in zip(password.ljust
(16,'\0')[:16], m.digest()[:16]))
Als een van de eigenschappen in het RADIUS-toegangsverzoek is gewijzigd (zoals de RADIUS-id, de User-Name, enzovoort), dan moet het veld nieuwe Authenticator worden gegenereerd en moeten alle andere velden die ervan afhankelijk zijn, opnieuw worden berekend. Als dit een heroverdracht is, zou niets moeten veranderen.
De betekenis van de header van de verificator is anders voor een toegangsaanvraag en een accounting-aanvraag.
Voor een toegangsaanvraag wordt de authenticator willekeurig gegenereerd en wordt verwacht dat hij een reactie ontvangt met de ResponseAuthenticator die correct berekend is, wat bewijst dat de respons gerelateerd was aan dat specifieke verzoek.
Voor een accounting-aanvraag is de Authenticator niet willekeurig, maar het wordt berekend (zoals per RFC 2866):
RequestAuth = MD5(Code + ID + Length + 16 zero octets + Attributes + Secret)
Op deze manier kan de server het accountantsbericht direct controleren en het pakket laten vallen indien de herberekende waarde niet overeenkomt met de waarde voor Authenticator. Identity Services Engine (ISE) retourneert:
11038 RADIUS Accounting-Request header contains invalid Authenticator field
De typische reden hiervoor is de onjuiste gedeelde geheime sleutel.
De eigenschap Message-Authenticator is de RADIUS-eigenschap gedefinieerd in RFC 3579. Het wordt voor een soortgelijk doel gebruikt: tekenen en valideren . Maar deze keer wordt het niet gebruikt om een antwoord maar een verzoek te valideren.
De client die een toegangsaanvraag verstuurt (het kan ook een server zijn die reageert met een Access-Challenge) compileert de Hash-Based Berichtverificatie Code (HMAC)-MD5 uit zijn eigen pakket en voegt vervolgens de eigenschap Message-Authenticator toe als een handtekening. Vervolgens kan de server controleren of het dezelfde handeling uitvoert.
De formule lijkt op de header van de verificator:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator,
Attributes)
De HMAC-MD5-functie voert twee argumenten in:
De Message-Authenticator moet worden gebruikt voor elk pakje, dat het MAP-bericht (Extensible Authentication Protocol) bevat (RFC 3579). Dit omvat zowel de client die het toegangsverzoek verstuurt als de server die met de toegangsuitdaging reageert. De andere zijde zou het pakket stilletjes moeten laten vallen als de validatie faalt.
De validatie zal mislukken wanneer het gedeelde geheim ongeldig is. Vervolgens kan de AAA-server het verzoek niet valideren.
De ISE meldt:
11036 The Message-Authenticator Radius Attribute is invalid.
Dit gebeurt meestal in de latere fase, wanneer het MAP-bericht wordt bijgevoegd. Het eerste RADIUS-pakket van de 802.1x-sessie bevat niet het MAP-bericht; er is geen veld Berichtverificatie en het is niet mogelijk het verzoek te verifiëren, maar in dat stadium kan de cliënt de reactie valideren met het gebruik van het veld Verificator.
Hier is een voorbeeld om aan te geven hoe u handmatig de waarde telt om ervoor te zorgen dat deze correct wordt berekend.
Packet nummer 30 (Access-Application) is geselecteerd. Het bevindt zich midden in de MAP-sessie en het pakket bevat het veld Berichtverificatie-authenticator. Het doel is te controleren of de Berichtverificatie correct is:
pluton # cat packet30-clear-msgauth.bin | openssl dgst -md5 -hmac 'cisco'
(stdin)= 01418d3b1865556918269d3cf73608b0
Hetzelfde kan worden berekend met behulp van het Python-schrift:
pluton # cat hmac.py
#!/usr/bin/env python
import base64
import hmac
import hashlib
f = open('packet30-clear-msgauth.bin', 'rb')
try:
body = f.read()
finally:
f.close()
digest = hmac.new('cisco', body, hashlib.md5)
d=digest.hexdigest()
print d
pluton # python hmac.py
01418d3b1865556918269d3cf73608b0
Het vorige voorbeeld geeft aan hoe het veld Berichtverificatie uit de toegangsaanvraag moet worden berekend. Voor Access-Challenge, Access-Accept en Access-Afwijs is de logica precies hetzelfde, maar het is belangrijk om te onthouden dat Application Authenticator moet worden gebruikt, wat in het vorige Access-Application pakket is voorzien.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
20-Jan-2016 |
Eerste vrijgave |