Subject: [AAA-WG]: digest issue 11 closure (fwd)

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Apr 2005 13:45:17 -0800 (PST)

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-masked]>
To: [email-masked]
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-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 04 Apr 2005 10:25:33 +0300

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

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Apr 2005 11:14:40 +0300

Let me expand on what I meant with "additional work" that
a R/D gateway needs to do. As originally envisioned, the Diameter
translation gateway was expected to be a mindless automaton,
blindly copying attributes to slightly different format. This would
be great, as the introduction of a new application or AVP would
not impact a gateway, or would only have a small impact. But we have
actually come quite far from this ideal, the current translation
rules for applications contain a number of attribute specific
processing rules.

I realize we have already started on this path, and there's no
turning back. Nevertheless, minimizing the necessary "coding"
or "mapping table construction" for translation gateways is
still valuable, as the simpler they are the easier they are to
implement.

I also realize that there are conflicting requirements. Ability
to clearly associate a particular set of attributes to a group
can be problematic (but doesn't that have to be solved for
RADIUS SIP anyway?). And grouping things inside on Grouped
AVP looks much nicer.

--Jari

Miguel Garcia wrote:

> some extra load. I believe this extra load is negligible compared to 
> the rest of AVPs the gateway will need to rebuild.
>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 04 Apr 2005 11:45:35 +0300

Minimizing the "coding" or "mapping table construnction" is a valuable 
argument when it has an impact on the processing time. But as I said 
before, this time is negligible compared to the time the gateway will 
use to process a request, so I don't see the point in destroying the 
clear structure we have in the Diameter SIP app for no visible gain.

/Miguel

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Apr 2005 12:18:12 +0300

> clear structure we have in the Diameter SIP app for no visible gain.
Perhaps I didn't make my argument clear, because you seem
to be talking about a different tradeoff than I am. My worry was
not anything that happens at run-time, I'm sure a translation
gateway spends less CPU time re-organizing AVPs than something
else, say TLS.

My worry was, however, about the need to have a specific
translation rule, which increases *implementation* time
and effort.

--Jari

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 04 Apr 2005 12:36:56 +0300

Hmmmm... I see the point. But I still believe a translation rule is 
needed, but not in the gateway, but in the RADIUS client (so this makes 
also the rule needed in the gateway).

Imagine: how is the SIP-server/RADIUS-client going to determine that it 
has to generate an Authentication-Info header when the RADIUS server 
returns a next nonce? I guess there is a rule that says "if 
Digest-Nextnonce attribute present, then generate Authentication-Info 
header in SIP". So this is the rule between RADIUS and SIP.

In Diameter SIP app, we don't have this problem, because the 
Digest-Nextnonce would be part of the SIP-Authentication-Info AVP.

So the point I want to make is that, due to the lack of grouped 
attributes in RADIUS, you do need translation rules in RADIUS in order 
to generate the appropriate HTTP/SIP digest header. And we don't have 
this problem in Diameter due to the usage of grouped AVPs. So the 
translation rules are in the RADIUS part of the gateway, not in the 
Diameter. You should fix the RADIUS draft if possible, rather than 
extend translation rules to native Diameter applications.

/Miguel