Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-sctp-auth-03 starts NOW

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Sep 2006 13:03:35 +0200

Hi,

A bit late, but I do have some comments on this document:

1. Section 3.

It should be noted that the parameter format requires the receiver to
    ignore the parameter and continue processing if it is not understood.
    This is accomplished as described in RFC2960 [4] section 3.2.1. by
    the use of the upper bits of the parameter type.

So the intention is that the mechanism that really require this to be 
used put the mandate on that? It seems that some mechanism should not go 
ahead in cases these parameters are ignored.

2. Section 3.1:

Parameter Length: 2 bytes (unsigned integer)
       This value is the length of the Random Number plus 4.

In what units are the length expressed, octets? In that case I would 
propose changing the above to:

Parameter Length: 2 bytes (unsigned integer)
       This value is the length of the Random Number in octets plus 4.

3. Section 3.3:

HMAC Identifier n: 2 bytes (unsigned integer)
       The values is an HMAC Identifier which should be used.  The values
       are listed by priority.  Highest priority first.

I am reacting to the formulation "which should be used". Isn't this 
algorithms that are supported by the end-point providing the parameter? 
I think more clear and precise language would be recommended here.

4. Section 3.3:

"The following Table 2 shows the currently defined values for HMAC
    identifiers.

               +-----------------+--------------------------+
               | HMAC Identifier | Message Digest Algorithm |
               +-----------------+--------------------------+
               | 0               | Reserved                 |
               | 1               | SHA-1 defined in [6]     |
               | 2               | MD-5 defined in [1]      |
               +-----------------+--------------------------+

                                   Table 2

    Every endpoint supporting SCTP chunk authentication MUST support the
    HMAC based on the SHA-1 algorithm."

Based on the latest recommendation from the sec area why isn't SHA-256 
the mandated algorithm? Also what are the motivation for including know 
weak algorithms like MD-5? I am worried that there might be some way for 
a man in the middle to do a type of bid-down attack to the weakest 
supported.

5. Section 6.1:
"The RANDOM
    parameter SHOULD contain a 32 byte random number."

Why is this 32 bits and when can it be of other lengths. I think the 
exception to the SHOULD be clearly spelled out. Also isn't 32-bit to 
short to provide sufficient security. It seems that using 128 bits each 
would provide better input to the key.

6. Section 6.1 and 6.2:

"The sender MUST calculate the MAC using the hash function H as
    described by the MAC Identifier and the shared association key K
    based on the endpoint pair shared key described by the shared key
    identifier."

The specification is not defining which bits out of K that should be 
used when the length of K does not match the length of the digest 
algorithms key. Also it is lacking specification for how to padd K if K 
is shorter than what the algorithm needs.

In addition, has there been any security analysis of what security 
properties this simple concatenation provides compared to hashed key 
creation etc that commonly is used when deriving keys?

It would probably be better to use a key derivation function, like RFC 
3380 section 4.1.2 which allows any length input, selected length output.

7.  Section 6.3, usage of TCB without explanation or reference.

8. Section 6.3:

It should also be noted that if an endpoint accepts ABORT chunks only
    in an authenticated way, it may take longer to detect that the peer
    is no longer available.  If an endpoint accepts COOKIE chunks only in
    an authenticated way, the restart procedure does not work.

What are the implication of accepting non-authenticated ABORT and COOKIE 
chunks? As currently written it encourage to ignore the authentication 
for these chunks. I think the paragraph should be more balanced.

9. Section 7:

If this intervention is not possible due to
    limitations of the API the server might discard the AUTH and DATA
    chunk making a retransmission of the DATA chunk necessary.

I don't understand how this is particular relevant. Shouldn't the 
application provide the SCTP stack with the key-chain prior to the INIT. 
Thus no issue.

10. Section 7:
If the
    same endpoint pair shared key is used for multiple endpoints and does
    not depend on the client this intervention might not be necessary.

This recommendation seem to be very bad from a security perspective.

11. Section 8.

There is no policy specified for what is required to register new digest 
algorithms. In addition the requirements on the digest algorithm is also 
not written up.

12. Section 9:

Without using endpoint shared keys this extensions only provides a
    way of making sure that chunks being authenticated are received from
    the same peer the association was established with.

I think this sentence is seriously overstating the security properties 
of the null key. To my understanding the only security property the null 
key has is it protects against off-path attacker that can't capture 
anything of the initial exchange. The next sentence tries to explain 
this, however the first one does overstate the properties and shouldn't. 
  I would recommend rewriting that first paragraph to be more accurate.

In addition I think this usage and its properties should clearly be 
explained in the introduction to ensure that no one misses this 
weakness. In fact I would like to discuss if this should be allowed at 
all. The Null key's security properties are very weak.

I would very much like to see a security review of this solution happen 
before progressing it past the WG. We chairs can help with creating the 
contact if necessary.

13. Section 9. Why isn't the issues of bid-down or selection of the 
weakest algorithm discussed in the security consideration?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]