Subject: [radext] RFC 5090 RADIUS client

From: Yehoshua Gev <[email-masked]>
Date: Mon, 9 Jul 2012 14:47:33 +0300

Hello all,

I hope that someone could answer some questions I have encountered with
when designing a SIP server supporting RFC 5090.

1. Configuration of realm
Section 2.1.1:
   The RADIUS
   client MUST choose the credential of the (Proxy-)Authorization header
   if the realm directive matches its ***locally configured*** realm.

Section 2.1.5:
   The RADIUS client constructs a (Proxy-)Authenticate header using the
   ***received*** Digest-Nonce and Digest-Realm attributes to fill the nonce
   and realm directives.

If the realm is determined by the RADIUS server, how would the RADIUS
client know which Authorization header to choose?
Should the RADIUS client remember the realms it had received on
Access-Challenge responses?

2. Storing the nonce
Section 2.1.2:
   If the RADIUS client recognizes the nonce, it takes the header
   directives and puts them into a RADIUS Access-Request packet.

How should the RADIUS client recognize the nonce if it was not generated by
it?
Should the RADIUS client keep state and store the nonce it had received on
the last Access-Challenge?

3. Statefulness
The RFC does not state whether the RADIUS client (HTTP-style server) can
work without keeping state.
Especially that it must respond with the State attribute in subsequent
Access-Request (section 5).

If I understand the digest authentication scheme correctly, I believe that
the opaque directive is used for state.
Can opaque be used to store the State attribute?
May the RADIUS client modify the opaque directive, to include the both
Digest-Opaque and State attributes?

Thank you very much,
Yehoshua Gev
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext