[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 123/124 Radius Digest requirement to clients
Proposal:
Section 1.3 Overview
[..]
The nonces required by the digest algorithm are either generated by
the RADIUS client or by the RADIUS server. A mix of nonce generation
modes is not supported. This specification assumes that both the
RADIUS client and server are appropriately configured to generate the
nonces in either the RADIUS client or the RADIUS server, but not in
both at the same time. Implementations, though, do not have the
means to verify this behavior.
New Section 2:
2. Interoperability
An implementation supporting this extension MUST include a Digest-
Response attribute within an Access-Request packet where Digest
Authentication is desired. An Access-Request MUST NOT contain both a
Digest-Response attribute and another authentication attribute, such
as User-Password, CHAP-Password, or EAP-Message.
RADIUS clients and servers MUST support both nonce generation modes.
As there is no automatic capability exchange, the operator MUST make
sure that the RADIUS client software uses the correct nonce
generation mode when accessing a specific RADIUS server:
o If the RADIUS server generates nonces, its RADIUS clients MUST NOT
try to generate nonces.
o If the RADIUS server does not generate nonces, its RADIUS clients
MUST generate nonces locally.
o If at least one HTTP-style client requires AKA authentication
[RFC3310], the RADIUS server MUST generate nonces and its RADIUS
clients MUST NOT generate nonces locally.
RADIUS implementations MUST offer respective configuration options.
(Section 2 removes also normative language from the overview section)
Wolfgang
--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>