[Issue] Comments to draft-ietf-radext-digest-auth-00.txt (fwd)

[Bernard Aboba <aboba@internaut.com>]

-------- Original Message --------
Subject: Comments to draft-ietf-radext-digest-auth-00.txt
Date: Wed, 15 Dec 2004 15:45:04 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
To: Beck01, Wolfgang <BeckW@t-systems.com>
CC: radiusext@ops.ietf.org

Wolfgang:

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.

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."


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.

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.


I hope you can take these comments into account.

Regards,

           Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland



-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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