AW: Comments on draft-sterman-aaa-sip-03

["Beck01, Wolfgang" <BeckW@t-systems.com>]

Pete McCann wrote:

> Document should start with an overview of the assumed architecture, as
> shown in e.g. Figure 1 of Section 1.3.  However, the text of Section
> 1.3 dives into a particular scenario and a broader overview is
> necessary first.  (I think Miguel made this comment earlier)
> Section 1.2 (although I think this text should be deleted):
When I started working on the draft, people asked for a motivational
section.

I'll do an overview section which includes the 2 scenario sections

     1.3   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.3.1   Scenario 1, RADIUS client chooses nonces . . . . . . .  5
       1.3.2   Scenario 2, RADIUS server chooses nonces . . . . . . .  6

Section 1.3 will be the '1.5 Approach' section of -03 without the last
paragraph.

>   However, in
>   some cases the RADIUS server is better off with pre-computed hashes.
>   Section 1.4 describes an mechanism that enables this style of
>   authentication.
> This paragraph mentions "precomputed hashes" but then the issue is never
> revisited.  Is it true that precomputed hashes can be used with arbitrary
> message contents, or is some other coordination required between the
> home RADIUS server and the client?
Proposal:
"1.3.2  Scenario 2, RADIUS server chooses nonces

   In most cases, the operation outlined in Section 1.3.1 is sufficient.
   It reduces the load on the RADIUS server to a minimum.  However, when
   using AKA [RFC3310] the nonce is partially derived from a precomputed
   authentication vector.  These authentication vectors are often stored
   centrally.

   Figure 3 depicts an scenario, where the RADIUS server chooses nonces."

> Section 2:
> Reformat list of attributes into a table, and use values like "TBD-DIG-RES"
> in the table.  Create an IANA considerations section which requests allocations.
There is a IANA consideration section at the end of the document. I didn't want
to use DIG-RES etc. in the sub sections of 2. before explaining that they are
attribute names.

Proposal:
"2.  New RADIUS attributes

   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
   are taken from the RADIUS attribute type number space (see Section 
   <IANA considerations>)."

> Don't use text like "if this specification becomes a working group or IESG
> document..."
> [..]
> Get rid of " Early implementations have used the experimental type
> 206."
Ok.

The following is confusing:

> 3.1  RADIUS Client Behaviour
> 
>    A RADIUS client without an encrypted or otherwise secured connection
>    to its RADIUS server only accepts unsecured connections from its
>    HTTP-style clients (or else the clients would have a false sense of
>    security).
> 
> It is not quite clear what is meant by "encrypted or otherwise
> secured", because there are several different security mechanisms
> available in RADIUS, including the hop-by-hop message authenticator
> and the shared-key method of obfuscating individual attributes.  I
"encrypted" ~ eg. IPSEC or proprietary tunnel technology
"otherwise secured" ~ eg. RADIUS client and server are in a closed MPLS
VPN.

> assume this would not be adequate to provide the protection you are
> looking for.  Also, what counts as an "unsecured connection" from an
> HTTP-style client?  Do you mean one that doesn't use either TLS or
> IPSec?
Yes. I'll insert a reference to the security considerations section,
which has this paragraph:
  "HTTP-style clients can use TLS with server side certificates together
   with HTTP-Digest authentication.  IPSec can be used in a similar way.
   TLS or IPSec secure the connection while Digest Authentication
   authenticates the user.  If a RADIUS client accepts such connections,
   it MUST have a secure connection to the RADIUS server."

> Maybe this paragraph is adequately covered by the security
> considerations (or should be) and could be deleted.
I disagree. If a SIP client wants the signalling to be secure,
it uses sips: URLs. All SIP proxies along the way must use TLS
connections to forward requests with sips: URLs. I don't think
the SIP proxies (=RADIUS clients) should expose parts of the SIP
message by using a unencrypted RADIUS messages in this case.

As this is part of the client behaviour, I put it into that section.


Thank you very much for your help,

Wolfgang


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