Re: : digest issue 11 closure (fwd)

I have filed his issue:

http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue47

Now, I asked sometime ago what would be the problem in having grouped 
AVPs that, in turn, contain Digest-* attributes imported from RADIUS. 
The answer I got (Jari), at that time, was, there shouldn't be a problem.

I still belive that grouped AVPs constitute a powerful mechanism to 
avoid problems (such as sequencing, repetition, etc.). I think that 
Jari's argument is weak ("this will create some overload to the 
gateway"). The gateway will need to do a bunch of other functions to 
translate RADIUS to Diameter, so I am not for the idea of constraining 
the protocol (Diameter) just because the gateway (to RADIUS) will have 
some extra load. I believe this extra load is negligible compared to the 
rest of AVPs the gateway will need to rebuild.

My opinion: I am in favor of leaving the grouped AVPs as they are.

/Miguel

Bernard Aboba wrote:

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

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland