3. Schema di autenticazione di accesso digest (Digest Access Authentication Scheme)

3.1 Introduzione (Introduction)

3.1.1 Scopo (Purpose)

Il protocollo denominato "HTTP/1.0" include la specifica per uno schema di autenticazione di accesso di base (Basic Access Authentication Scheme) [1]. Questo schema non è considerato un metodo sicuro di autenticazione degli utenti, poiché il nome utente e la password vengono trasmessi sulla rete in forma non crittografata. Questa sezione fornisce la specifica per uno schema che non invia la password in chiaro, ma utilizza invece una tecnica di checksum, denominata "Autenticazione di accesso digest" (Digest Access Authentication).

Lo schema di autenticazione di accesso digest non è destinato a essere una risposta completa alla necessità di sicurezza sul World Wide Web. Questo schema non fornisce la crittografia del contenuto dei messaggi. L'intento è semplicemente quello di creare un metodo di autenticazione di accesso che eviti i difetti più gravi dell'autenticazione di base.

3.1.2 Operazione complessiva (Overall Operation)

Come l'autenticazione di accesso di base (Basic Access Authentication), lo schema digest si basa su un semplice paradigma sfida-risposta (Challenge-Response Paradigm). Lo schema digest sfida utilizzando un valore nonce. Una risposta valida contiene un checksum (per impostazione predefinita, il checksum MD5) del nome utente, della password, del valore nonce fornito, del metodo HTTP e dell'URI richiesto. In questo modo, la password non viene mai inviata in chiaro. Come con lo schema di base, il nome utente e la password devono essere preordinati in qualche modo non affrontato da questo documento.

3.1.3 Rappresentazione dei valori digest (Representation of digest values)

Un header opzionale consente al server di specificare l'algoritmo utilizzato per creare il checksum o il digest. Per impostazione predefinita viene utilizzato l'algoritmo MD5, che è l'unico algoritmo descritto in questo documento.

Ai fini di questo documento, un digest MD5 di 128 bit è rappresentato come 32 caratteri ASCII stampabili. I bit del digest a 128 bit vengono convertiti dal bit più significativo al bit meno significativo, quattro bit alla volta, nella loro rappresentazione ASCII come segue. Ogni gruppo di quattro bit è rappresentato dalla sua familiare notazione esadecimale dai caratteri 0123456789abcdef. Cioè, binario 0000 è rappresentato dal carattere '0', 0001 da '1', e così via fino alla rappresentazione di 1111 come 'f'.

3.1.4 Limitazioni (Limitations)

Lo schema di autenticazione digest descritto in questo documento soffre di molte limitazioni note. È destinato a sostituire l'autenticazione di base e nient'altro. È un sistema basato su password e (lato server) soffre di tutti gli stessi problemi di qualsiasi sistema di password. In particolare, non è prevista alcuna disposizione in questo protocollo per l'accordo iniziale sicuro tra utente e server per stabilire la password dell'utente.

Gli utenti e gli implementatori dovrebbero essere consapevoli che questo protocollo non è sicuro come Kerberos e non è sicuro come qualsiasi schema a chiave privata lato client. Tuttavia è meglio di niente, meglio di ciò che è comunemente usato con telnet e ftp, e meglio dell'autenticazione di base.

3.2 Specifica degli header digest (Specification of Digest Headers)

Lo schema di autenticazione di accesso digest è concettualmente simile allo schema di base. I formati per la linea header WWW-Authenticate modificata e la linea header Authorization sono specificati di seguito. Inoltre, è specificato anche un nuovo header, Authentication-Info.

3.2.1 L'header di risposta WWW-Authenticate (The WWW-Authenticate Response Header)

Se un server riceve una richiesta per un oggetto protetto da accesso e non viene inviato un header Authorization accettabile, il server risponde con un codice di stato "401 Unauthorized" e un header WWW-Authenticate secondo il framework definito sopra, che per lo schema digest viene utilizzato come segue:

challenge        =  "Digest" digest-challenge

digest-challenge  = 1#( realm | [ domain ] | nonce |
                    [ opaque ] |[ stale ] | [ algorithm ] |
                    [ qop-options ] | [auth-param] )

domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
URI               = absoluteURI | abs_path
nonce             = "nonce" "=" nonce-value
nonce-value       = quoted-string
opaque            = "opaque" "=" quoted-string
stale             = "stale" "=" ( "true" | "false" )
algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" | token )
qop-options       = "qop" "=" <"> 1#qop-value <">
qop-value         = "auth" | "auth-int" | token

I significati dei valori delle direttive utilizzate sopra sono i seguenti:

realm (dominio)

• Una stringa da visualizzare agli utenti in modo che sappiano quale nome utente e password utilizzare. Questa stringa dovrebbe contenere almeno il nome dell'host che esegue l'autenticazione.

domain (dominio)

• Un elenco di URI separati da spazi e tra virgolette che definiscono lo spazio di protezione (Protection Space).

nonce

• Una stringa di dati specificata dal server che dovrebbe essere generata in modo univoco ogni volta che viene effettuata una risposta 401. Si raccomanda che questa stringa sia dati base64 o esadecimali.

opaque (opaco)

• Una stringa di dati, specificata dal server, che dovrebbe essere restituita dal client invariata nell'header Authorization delle richieste successive con URI nello stesso spazio di protezione.

stale (obsoleto)

• Un flag che indica che la richiesta precedente del client è stata rifiutata perché il valore nonce era obsoleto. Se stale è TRUE (non sensibile alle maiuscole), il client può semplicemente riprovare la richiesta con una nuova risposta crittografata, senza richiedere nuovamente all'utente un nuovo nome utente e password.

algorithm (algoritmo)

• Una stringa che indica una coppia di algoritmi utilizzati per produrre il digest e un checksum. Se questo non è presente, si presume che sia "MD5".

qop-options (opzioni di qualità della protezione)

• Questa direttiva è opzionale, ma è resa tale solo per la compatibilità all'indietro con RFC 2069 [6]; dovrebbe essere utilizzata da tutte le implementazioni conformi a questa versione dello schema digest.

3.2.2 L'header di richiesta Authorization (The Authorization Request Header)

Ci si aspetta che il client riprovi la richiesta, passando una linea header Authorization con la direttiva response calcolata come specificato di seguito.

credentials      = "Digest" digest-response
digest-response  = 1#( username | realm | nonce | digest-uri
                   | response | [ algorithm ] | [cnonce] |
                   [opaque] | [message-qop] |
                   [nonce-count]  | [auth-param] )

username         = "username" "=" username-value
username-value   = quoted-string
digest-uri       = "uri" "=" digest-uri-value
digest-uri-value = request-uri
message-qop      = "qop" "=" qop-value
cnonce           = "cnonce" "=" cnonce-value
cnonce-value     = nonce-value
nonce-count      = "nc" "=" nc-value
nc-value         = 8LHEX
response         = "response" "=" request-digest
request-digest   = <"> 32LHEX <">
LHEX             = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                   "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f"

3.2.3 L'header Authentication-Info (The Authentication-Info Header)

Il campo header Authentication-Info può essere utilizzato dal server in una risposta per trasmettere informazioni sull'autenticazione riuscita. Questo header è particolarmente utile con la qualità di protezione "auth-int".

AuthenticationInfo = "Authentication-Info" ":" auth-info
auth-info          = 1#(nextnonce | [ message-qop ]
                     | [ response-auth ] | [ cnonce ]
                     | [nonce-count] )
nextnonce          = "nextnonce" "=" nonce-value
response-auth      = "rspauth" "=" response-digest
response-digest    = <"> *LHEX <">

3.3 Operazione digest (Digest Operation)

L'operazione dell'autenticazione di accesso digest è la seguente. Il client effettua una richiesta al server, che sfida con una risposta 401 fornendo un nonce e altri parametri. Il client utilizza questi parametri per calcolare il valore di risposta e lo invia insieme ad altre informazioni in una richiesta successiva al server. Il server verifica il valore di risposta e, se corretto, concede l'accesso.

3.4 Negoziazione del protocollo di sicurezza (Security Protocol Negotiation)

Un server può fornire più sfide nell'header WWW-Authenticate, ciascuna utilizzando uno schema di autenticazione diverso. Il client dovrebbe selezionare lo schema più forte che supporta.

3.5 Esempio (Example)

L'esempio seguente presuppone che l'accesso al documento protetto richieda l'autenticazione. Il server sfida con una risposta 401:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
    realm="[email protected]",
    qop="auth,auth-int",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    opaque="5ccc069c403ebaf9f0171e9517f40e41"

Il client può rispondere con il seguente header Authorization:

Authorization: Digest username="Mufasa",
    realm="[email protected]",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    uri="/dir/index.html",
    qop=auth,
    nc=00000001,
    cnonce="0a4f113b",
    response="6629fae49393a05397450978507c4ef1",
    opaque="5ccc069c403ebaf9f0171e9517f40e41"

3.6 Proxy-Authentication e Proxy-Authorization

L'autenticazione e l'autorizzazione del proxy funzionano in modo simile all'autenticazione e all'autorizzazione del server di origine, ma utilizzano i campi header Proxy-Authenticate e Proxy-Authorization. Il proxy deve essere completamente trasparente nella gestione dell'autenticazione tra il client e il server di origine.

---