Passa al contenuto principale

9. Change Log (Registro delle Modifiche)

9. Change Log (Registro delle Modifiche)

Le seguenti modifiche sono state apportate rispetto a RFC 2138:

Le stringhe dovrebbero utilizzare UTF-8 invece di US-ASCII e dovrebbero essere gestite come dati a 8 bit.

Gli interi e le date sono ora definiti come valori senza segno a 32 bit.

Elenco aggiornato degli attributi che possono essere inclusi in Access-Challenge per essere coerente con la tabella degli attributi.

User-Name menziona i Network Access Identifier.

User-Name può ora essere inviato in Access-Accept per l'uso con accounting e Rlogin.

Valori aggiunti per Service-Type, Login-Service, Framed-Protocol, Framed-Compression e NAS-Port-Type.

NAS-Port può ora utilizzare tutti i 32 bit.

Gli esempi ora includono visualizzazioni esadecimali dei pacchetti.

Termination-Action è stato chiarito.

La discussione proxy è stata notevolmente ampliata e chiarita.

La sezione "Why UDP?" (Perché UDP?) è stata ampliata.

La sezione "Retransmission Hints" (Suggerimenti per la Ritrasmissione) è stata ripulita.

Il testo "silently discard" (scartare silenziosamente) è stato chiarito nella sezione Terminology (Terminologia).

I requisiti per NAS-IP-Address e NAS-Identifier sono stati chiariti.

Il campo Vendor-Id nell'attributo Vendor-Specific è stato reso più conforme alle linee guida IANA.

Il testo è stato aggiunto sul fatto che gli attributi dello stesso tipo non devono essere contigui.

Il testo sulle password in chiaro in RFC 2138 è stato rimosso.

Il testo è stato aggiunto per raccomandare che il segreto condiviso non dovrebbe essere vuoto.

Il testo è stato aggiunto per specificare il comportamento quando il server RADIUS non può eseguire l'autenticazione richiesta (ad es. CHAP quando la password dell'utente non è disponibile in chiaro).

La sezione IANA Considerations (Considerazioni IANA) è stata aggiunta.

La sezione Security Considerations (Considerazioni sulla Sicurezza) è stata ampliata.

Il campo Identifier è stato chiarito per quando deve cambiare.

L'esempio di User-Password e la descrizione sono stati corretti per includere i casi in cui la password è più lunga di 16 ottetti.

Il testo è stato aggiunto per specificare che le implementazioni DEVONO essere in grado di gestire valori null incorporati nelle stringhe.

È stato aggiunto che Request Authenticator deve essere imprevedibile.

La sezione implementazione delle estensioni future è stata chiarita. Gli attributi di autenticazione futuri possono essere utilizzati al posto di User-Password o CHAP-Password in un Access-Request.

La sezione sulla gestione degli attributi sconosciuti è stata chiarita.

La discussione su come e quando utilizzare l'attributo Class è stata ampliata.

La sezione sui requisiti di conformità è stata ampliata per includere quando una conformità "condizionale" è accettabile.