AW: Comments to draft-ietf-radext-digest-auth-00.txt

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

Hi Miguel,

You wrote: 
> I took a look at draft-ietf-radext-digest-auth-00.txt, based on the 
> comments that I posted to an earlier version of the draft. I 
> still have 
> a few comments:
> 
> 1) Section 4.1 has a table that maps RADIUS attributtes to 
> Diameter SIP 
> app. AVPs. I think this table is no longer needed, since Diameter SIP 
> app imports (or will import in forthcoming version -05) the Digest-* 
> attributes from your draft.
> 
> Specifically, Diameter SIP app imports Digest-Method and 
> Digest-URI from 
> your draft, so there is no mapping at all. Therefore, Table 1 in your 
> draft has to be removed.

diameter-sip-app-05 has additional SIP-AOR and SIP-Method AVPs, which have
no counterpart in radext-digest-auth-00. I think you defined SIP-AOR and
SIP-Method to be able to authorize actions of users ("User 'User-Name' is
allowed to send messages with a method 'SIP-Method' and AOR SIP-AOR").

Should I add SIP-Method, SIP-AOR (HTTP-Method, SIP-AOR?) to radext-digest-auth-00?
On the other hand, why stop with method and aor; providers might by interested
in authorizazion by Content-Type or even SDP header contents.

> 
> 
> 2) We discussed an atypical case when a SIP request contains 
> more than 
> one set of credentials, perhaps because the request traversed several 
> proxies and each one authenticated the user. We agree to add some 
> discussion, and the only text I found (correct me if I am 
> wrong), is a 
> bit weak in my opinion:
> 
>     On reception of an HTTP-style request message, the RADIUS client
>     looks for a (Proxy-)Authorization header where the realm directive
>     matches its locally configured realm value.
> 
> I would suggest to add a bit more of descriptive text, it is 
> never a bad 
> idea. I send you the text I added to the Diameter SIP app 
> draft, you can 
> copy/adapt/modify if you want:
> 
> "There are situation where a SIP request traverses several 
> proxies, and 
> each of the proxies request to authenticate the SIP UA. In this 
> situation, it is a valid scenario that a SIP request received 
> at a SIP 
> server contains several sets of credentials. The 'realm' directive in 
> HTTP is the key that the Diameter client can use to determine which 
> credential is applicable. It may happen also that none of the 
> realms are 
> of interests to the Diameter client, in which case the 
> Diameter client 
> MUST consider that no credentials (of interest) were sent. In 
> any case, 
> a Diameter client MUST send zero or exactly one credential to the 
> Diameter server. The Diameter client MUST choose the 
> credential based on 
> the 'realm' directive in the Authorization/Proxy-Authorization header 
> field, and it MUST match the realm of the Diameter client."
> 
I will adapt and include this text.


> 3) We spoke that Digest-Response and Digest-Response-Auth 
> attributes had 
> an artificial limit of 32 octets, and I proposed to avoid having any 
> limit. The current version of the draft indicates that these 
> attributes 
> have a lenght >= 34 (32 octets + the length + the attribute 
> type). This 
> allows future expansion if the size goes further than 32, but 
> not if the 
> size decreases. While it is unlikely that new algorithms will 
> decrease 
> this size, since I don't have a ball to guess the future, I still 
> propose to have this size unlimited, i.e., Length => 3.
Ok.

> 4) I had another comment regarding the 'qop' parameter in 
> HTTP Digest. 
> The problem is that this pararameter can contain several values, for 
> example, qop=auth,auth-int. The draft should indicate how to 
> encode in 
> Radius this several parameters. I haven't found this described yet.
> 
> We had a discussion on the mailing list and I expressed my preference 
> for option b, that I repeat below:
> 
>    b) Each token is an attribute, thus, there might be multiple
>       Digest-Qop attributes in a particular Radius/Diameter message.
See section 3.2

"The RADIUS server MUST add Digest-Algorithm, Digest-Realm,
   SHOULD add one or more Digest-Qop and MAY add Digest-Domain,
   Digest-Opaque attributes to the Access-Challenge message.  If the
   server cannot choose a nonce, it replies with an Access-Reject
   message."

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/>