: digest issue 11 closure (fwd)

Note: Jari is opening a new issue within the Diameter SIP document.

---------- Forwarded message ----------
Date: Thu, 24 Mar 2005 16:49:18 +0200
From: Jari Arkko <[email protected]>
To: [email protected]
Subject: 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 [email protected] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>