[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
review of draft-sterman
Hi Wolfgang, (cc Miguel)
I know I'm late, but here are a few comments on draft-sterman:
Technical:
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).
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.
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 :-)
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.
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).
(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.
Alternative idea: use some of the extended RADIUS attribute
format ideas and allocate the numbers from the Diameter space.
(3) Use exactly the set of attributes for the pure digest function
(I did not check if this is already the case).
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
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?
Other ideas?
Editorial:
Basic and Digest authentication schemes are widely used in protocols
such as SIP and HTTP . RADIUS is a protocol for back end
s/HTTP ./HTTP./
support HTTP digest authentication only. Its interopability with a
back-end authentication protocol such as RADIUS is needed.
s/interopability/interoperability/
o build a PKI and wait for interopable S/MIME capable SIP
implementations,
s/interopable/interoperable/
SIP service providers whishing to authenticate their clients have the
following options: they can
s/whishing/wishing/
Basic and Digest authentication schemes are widely used in protocols
such as SIP and HTTP . RADIUS is a protocol for back end
Sterman, et al. Expires November 30, 2004 [Page 1]
Internet-Draft RADIUS Extension for Digest Authentication June 2004
authentication. RADIUS supports Basic authentication natively, as
well as several other authentication schemes, such as CHAP, but does
not support Digest authentication scheme. This document describes an
extension to RADIUS for Digest authentication and provides a scenario
of Digest user authentication.
What abbreviations need to be expanded in the abstract (or possibly
also in the title)? The used acrynyms are: RADIUS, SIP, HTTP, CHAP.
--
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/>