AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03

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

Miguel,

> 1) Abstract: The abstract looks more like an introduction to me, 
> providing a motivation for this work. I think the abstract should just 
> indicate what this document provides, rather than a historical 
> description of the capabilities of RADIUS, SIP and HTTP. I would suggest 
> a text around this lines:
> 
> "This document specifies an extension to RADIUS that allows a RADIUS 
> client in a SIP/HTTP server, upon reception of a SIP/HTTP request, 
> retrieve and compute Digest authentication information from a RADIUS 
> server. Additionally, a scenario describing  the authentication of a 
> user emiting a SIP/HTTP request is provided."
Thank you for this proposal.

> 3) draft-sterman defines a Digest-Body attribute. But actually, the 
> attribute will not contain a body, but the hash of a body. I would 
> suggest to rename this attribute to Digest-Entity-Body-Hash. It happens 
> that this is the name of the same AVP in Diamter SIP app.
Digest-Body-Digest looked a bit strange to me and Digest-Entity-Body-Hash
a bit long. But I've no problem changing it.

> 4) I noticed that draft-sterman does not specified a Digest-Nextnonce 
> attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It 
> seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. 
> While the mechanism probably works, I would suggest to define a new 
> Digest-Nextnonce attribute in draft-sterman, since the semantics of 
> Nonce and Nextnonce are completely different, so they are sent in 
> different parameters in the Digest header. Is this acceptable?
> 
> 5) Similar to #4 above, I noticed that draft-sterman defines a 
> Digest-Response that presumably is used to map it to both "response" and 
> "rspauth" in Digest. As in #4, the semantics of both Digest parameters 
> are different, so the attributes should be. In Diameter SIP app. we 
> define Digest-Response and Digest-Response-Auth AVPs. I would suggest 
> that draft-sterman splits Digest-Response similarly. Is this acceptable?
After converting the draft to flat attributes, I tried to save attribute
space. It is a scarce resource in RADIUS.

> 6) Question of documentation. I noticed that all the attribute 
> descriptions in draft-sterman include a figure containing the position 
> of Type, Length and String. I wonder if it is needed to repeat the 
> figure in all the attribute descriptions or whether you can indicate in 
> a general paragraph the commonality shared by all the attributes (among 
> others, the structure represented in those figures).
OK.

> 7) Section 2.1 in draft-sterman. The definition of Type says:
>      Type
>           DIG-RES for Digest-Response.  Early implementations have used
>           the experimental type 206.
> 
>     I would suggest to remove the last sentence. It is not relevant for 
> this document the value an early implementation has used or not. What is 
> important is the value assigned by IANA.
OK.

> 8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter 
> SIP app are not synchronized with the possible values of this attribute.
> 
> Draft-sterman indicates that if Digest-Stale is present, its value will 
> always be set to "1". This will be mapped to the stale="true" parameter 
> in Digest. I understan that if Digest-Stale is not present, then the 
> RADIUS client should assume that stale="false" or simple not present in 
> Digest
> [..]
> My proposal is that draft-sterman aligns with Diameter SIP app and the 
> value of the Digest-Stale AVP includes a quoted string that is straight 
> forward mapped to the stale parameter in Digest. Is this acceptable?
Yes.

> In general, I found that this section 4 has to be rewritten once we 
> agree on the proposals in this e-mail. It would become easier to map 
> both documents now.
There will be some more changes as I will use Access-Challenge in the next
version of the draft.  

> 11) Section 5:
> 
> I would expect that this section starts with the following sentence:
>
> "This document serves as IANA registration request for ..."
> 
> Particularly, I would remove the dependency on becoming a working group 
> (item) or IESG document.
OK.

> 12) Examples in Section 7:
> 
> This one was a shock to me. It violates all the rules of writing RFCs. 
> For instance, it does not use the IP address space suggested for 
> examples, it does not use the example.com domain name.
> 
> The SIP examples luck a few mandatory headers (e.g., Max-Forwards), 
> contains the name of commertial products, contains undocumented 
> extensions to SDP, misses recommendations of populating several SIP 
> headers and SDP lines...
> 
> If you want to continue in this path, I may suggest that an expert 
> reviewer assigned by the transport AD should inspect this examples.
> 
> I have a better suggestion: at the end of the day, this draft is about 
> Digest and RADIUS. So why don't you focus on Digest and RADIUS in the 
> examples? create some sort of abstract SIP/HTTP request, and just write 
> down the Digest headers, but not the whole SIP message.
To be honest, I took the examples without much review from the -00 version
which was based on RfC 2543. 

Thank you for this detailed review,

Wolfgang

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt 

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