[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: review of draft-sterman
Hi Jari,
>> Due to the weaknesses of Digest authentication (see Section 6),
>
> Section 6 does not talk about the weaknesses of Digest authentication
> (original RFC reference might give you some security considerations;
> I'm not sure if there's any other document that would talk the
> issue).
Section 6 of draft-sterman references section 4 of RfC 2617. Ok,
too many levels of indirections here.
> Due to the weaknesses of Digest authentication (see Section 6),
> PKI-based authentication and encryption mechanisms have been
> introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However,
>
> Digest, TLS, and S/MIME are not necessarily in direct
> competition with each other, as they provide slightly different
> services. For instance, TLS is hbh, and Digest gives you
> freshness which S/MIME does not. Plus all three protect
> different parts of the SIP message.
>
> Suggestion: soften the above statement a bit.
HTTP Digest used to be the only security mechanism for SIP.
TLS and S/MIME cover the holes that HTTP digest left open.
>> SIP service providers whishing to authenticate their clients have the
>> following options: they can
>> o build a PKI and wait for interopable S/MIME capable SIP
>> implementations,
>> o build a PKI and wait for SIP implementations supporting TLS with
>> client-side certificates,
>> o replace their existing RADIUS infrastructure with DIAMETER
>> [RFC3588], when DIAMETER supports HTTP Digest authentication,
>> o use TLS for server authentication and plaintext passwords (Basic)
>> for client authentication, which can be done with standard RADIUS,
>> o upgrade their existing RADIUS servers with the functionality
>> described in this document
>>
>> 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].
>
> 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.
>> 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'
>> 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)."
> (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.
> 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.
> (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.
> 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."
Thanks for your review,
Wolfgang
--
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/>