[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: review of draft-sterman

Beck01, Wolfgang wrote:

Somehow the above arguments feel a bit out of place here. Just
state that Digest is widely used in SIP, and leave it at that :-)


Some people wanted a motivational section. Some people complained
about that section. I will shorten it.


Fair enough.

  PKI solutions only cover authentication, not authorization (EAP could
  change this, but its use with SIP is not standardized).  TLS / Basic
  authentication works only with the limited number of SIP devices that
  implement TLS.  Basic authentication has been deprecated for SIP in
  [RFC3261].

  Current RADIUS-based AAA infrastructures have been built and debugged
  over years.  Deficiencies of RADIUS have been mitigated with
  proprietary (ie costly) extensions.  Operators are therefore
  reluctant to replace their RADIUS infrastructure in order to enable a
  single new authentication mechanism.


Same as above. And I'm not sure all deficiences have been
mitigated.

'Deficiencies of RADIUS ..' --> 'Some deficiencies of RADIUS' 

Ok.

  DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
  DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
  DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
  will be assigned by IANA, if this specification becomes a working
  group or IESG document.


Here's an idea: I'd prefer the attributes in this and the Diameter
draft to be constructed with the following rules:

(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
   and Dig-Authp could all use the same attribute? They all have
   the same syntax in HTTP (param=value).


Well, I did this for nonce and nextnonce, response and rspauth.
Some reviewers found this ugly:

Miguel Garcia:
"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?"

Bernard Aboba:
"Also, saving attribute space is not a design goal of this document.
Diameter compatibility *is* a design goal."

And a guy named Jari Arkko wrote on Mo 09.08.2004 :-)
"In general, I'd rather have a larger number of attributes
in a draft than cause problems for translation. Of course
we can build special cases for attributes, but I'd rather
have NASREQ-style completely automatic mapping (attribute =>
AVP from RADIUS space) or at least simple table driven
mapping (attribute => AVP from Diameter space with same
type)."


I can see that I possibly contradicted myself as far
as number of attributes goes :-( Anyway, my main priority is
that the SIP and Diameter versions work with automatic
translation (item 2) and that you and Miguel agree on
the attributes that should be used (item 3). I don't think
the number of attributes is a limiting factor in terms of
available space; you should design the attributes so that
people like the resulting set. My original thought in the
review was that it would be cleaner if the attributes that
looked the same syntactically were transported in the same attribute.
But I understand the argument that the parameters have different
functions, and I guess this is what other people are saying
makes the parameter merging look ugly. I'm OK with that approach
too.

(2) If both RADIUS and Diameter are going to define the attributes,
   IMHO it would make sense to allocate them from the RADIUS space
   so a conversion box would not have to map attributes.


not easy. 

Can you elaborate why this would not be easy?

   Alternative idea: use some of the extended RADIUS attribute
   format ideas and allocate the numbers from the Diameter space.


This would introduce a new dependency on other drafts. 

Yeah, I just included the suggestion for completeness'
sake. I'd prefer the RADIUS space allocation.

(3) Use exactly the set of attributes for the pure digest function
   (I did not check if this is already the case).



   +-----+           +-----+           +-----+


The choice between the server and client generated
nonces: is there some guidance on how the client knows
which one to do? if it believes it may have a user that
does Digest AKA then it should do use the server generated
scheme? But how would it know this in a roaming case?


If you are expecting AKA users, you have to use server
generated nonces.


I guess my question was how do you know you are expecting
AKA users. Is there a fallback in case we were NOT expecting
them but one showed up because our roaming partner started
supporting AKA yesterday?

What does DIAMETER SIP do in this case? Always assume the additional
roundtrip?

What abbreviations need to be expanded in the abstract (or possibly
also in the title)? The used acrynyms are: RADIUS, SIP, HTTP, CHAP.


RfC 2866 (RADIUS Accounting) uses the abbreviation
RfC 2617 (HTTP Digest) uses the abbreviation, too.
CHAP has already been eliminated from the abstract.
Proposal:
"Several protocols use HTTP digest authentication.  This document specifies
an extension to RADIUS that allows a RADIUS client in a server, upon
reception of a request, retrieve and compute Digest authentication
information from a RADIUS server.  Additionally, a scenario describing
the authentication of a user emiting a request is provided."


Ok.

--Jari


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