[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
digest issue 11 closure
Checking from the issue tracker this issue and comparing
it against -01. Here's what I found:
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).
Ok.
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.
Ok (but a nit: s/The majority of today's SIP clients only supports HTTP
digest./
The majority of today's SIP clients only support HTTP digest, however./
(I think Bernard caught this already so this is not a reason to keep my
issue alive.)
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 :-)
Ok.
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.
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).
(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).
Ok, this is mostly as I wanted it to be in the Radius document.
However, I wonder if the current Diameter document should
use individual AVPs instead of Grouped AVP:
SIP-Authenticate ::= < AVP Header: xx12 >
{ Digest-Realm }
{ Digest-Nonce }
[ Digest-Domain ]
[ Digest-Opaque ]
[ Digest-Stale ]
[ Digest-Algorithm ]
[ Digest-QoP ]
[ Digest-HA1]
* [ Digest-Auth-Param ]
* [ AVP ]
Because translating this grouped AVP appears to require
additional work from a gateway, no? Bernard/Miguel, can
you file on issue to the Diameter document on this.
+-----+ (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?
This has been raised by Bernard too, apparently we
didn't do good enough job to fix it.
Conclusion: close issue 11. Bernard's roaming issue
still needs to be kept alive, and I'm suggesting one
new issue on the Diameter SIP document.
--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/>