digest-auth: proposed text for SIP-AOR, Realm

["Beck01, Wolfgang" <BeckW@t-systems.com>]

to close issue 53, I propose the following text:

2.20  SIP-AOR

   This attribute is for the authorization of SIP messages.

   Type
         [IANA:use 121 if possible] for SIP-AOR
   Length
         >=3
   String
         The syntax of this attribute corresponds either to a SIP URI
         (with the format defined in [RFC3261] or a TEL URI (with the
         format defined in [RFC3966]).
         The SIP-AOR attribute identifies the URI the use of which must
         be authenticated.  The RADIUS server uses this attribute to
         authorize the processing of the SIP request.  The SIP-AOR can
         be derived from, e.g., the To header field in a SIP REGISTER
         request (user under registration), or the From header field in
         other SIP requests.  However, the exact mapping of this
         attribute to SIP can change due to new developments in the
         protocol.
         This attribute MUST only be used when the RADIUS client wants
         to authorize SIP users and MUST only be used in Access-Request
         messages.

Issue 43, choosing the correct credentials from a set of authorization headers:

RADIUS Client Behaviour
[..] 
On reception of an HTTP-style request message, the RADIUS client checks
whether it is responsible to authenticate the request.
There are situation where an HTTP-style request traverses several proxies,
and each of the proxies request to authenticate the HTTP-style client. In
this situation, it is a valid scenario that a HTTP-style request received
at a HTTP-style server contains several sets of credentials. The 'realm'
directive in HTTP is the key that the RADIUS client can use to determine
which credential is applicable. It may happen also that none of the
realms are of interests to the RADIUS client, in which case the RADIUS
client MUST consider that no credentials (of interest) were sent. In
any case, a RADIUS client MUST send zero or exactly one credential to
the RADIUS server. The RADIUS client MUST choose the credential of the
(Proxy-)Authorization header where the realm directive matches its locally
configured realm value.  If such a header is present and contains HTTP
digest information, the RADIUS client checks the 'nonce' parameter.
If the RADIUS client generates nonces but did not issue the received
nonce, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication
Required) to the HTTP-style client. In this error response, the RADIUS
client sends a new nonce.


Wolfgang

--
T-Systems
Internet Platforms
+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/>