Subject: [Tsvwg] AD evaluation comments on draft-ietf-tsvwg-sctp-auth-06

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Dec 2006 13:43:02 +0100

Hi,

I was doing my AD eval of the SCTP AUTH draft and have a few question 
and comments.

1. Are there a good reason for not signing INIT and INIT-ACK? I do 
understand that both end-points do not have each others random value. 
However if one has a shared secret prior, having the INIT being signed 
by RANDOM|KEY and the INIT ACK being signed with the full key as the 
peer will return his random value in the INIT ack would allow that even 
the establishment to be signed. Thus preventing MITM attacks on 
algorithm choice. It would also allow a SCTP end-point to only create 
associations from trusted peers.

2. Section 6.1, third paragraph:

"An SCTP
    endpoint MUST NOT change the parameters listed in the HMAC-ALGO
    parameter during the lifetime of the endpoint."

I don't understand what "lifetime of the endpoint" actually means. Is it 
meaning as long as this host does not replace its OS, until it reboots 
the next time, or what?

3. Section 6.1:

   "From the endpoint pair shared keys and the key numbers the
    association shared keys are computed.  This is performed by selecting
    the smaller key number and concatenating it to the endpoint pair
    shared key, and then concatenating the larger of the key numbers to
    that.  If both key numbers are equal, then the concatenation order is
    the endpoint shared key, followed by the key number with the shorter
    length, followed by the key number with the longer length.  If the
    key number lengths are the same, then they may be concatenated to the
    endpoint pair key in any order.  The concatenation is performed on
    byte vectors representing all numbers in network byte order.  The
    result is the association shared key."

First of all I don't think using the complete string as a number was a 
particular bright idea, due to the issues of comparing them as numbers. 
I would have preferred that one first looked at the length and then the 
value. That way one could have started comparing the most significant 
word that your architecture supported. But with the added requirement 
that the RANDOM parameter value always is 32 bytes I don't see that is 
has any real impact.

4. Section 6.3
"  If the receiver does not find a STCB for a packet containing an AUTH
    chunk as a first chunk and a COOKIE-ECHO chunk as the second chunk
    and possibly more chunks after them, the receiver MUST authenticate
    the chunks by using the random numbers included in the COOKIE-ECHO,
    and possibly the local shared secret.  If authentication fails then
    the packet discarded.  If the authentication is successful the
    COOKIE-ECHO and all chunks after the COOKIE-ECHO MUST be processed.
    If the receiver has a STCB, it MUST process the AUTH chunk as
    described above using the STCB from the existing association to
    authenticate the COOKIE-ECHO chunk and all chunks after it."

At least when I come to this paragraph, I was missing some context. I 
had a hard time understanding if the above text was something general or 
applying to a particular case. After having read on and thought about it 
I do realize that it applies to the particular case when sending a 
cookie echo. Can you please include some introductory sentences that 
explain in which context the above applies.

5. section 6.3:

"If authentication fails then the packet discarded."

Please correct language is above, missing "is" before discarded.

6. Sect ion 6.3:

"If an endpoint accepts
    COOKIE-ECHO chunks only in an authenticated way, the restart
    procedure does not work."

Sorry for being dense, but why does not the restart procedure work? Are 
you assuming that a end-point having being restarted will have lost the 
RANDOM values associated with the association that existed prior to the 
peer restarting?

It would be good if you would update the document after having resolved 
the discussion points above.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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]
----------------------------------------------------------------------

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Dec 2006 15:46:22 +0100

Hi Magnus,

see my comments in-line.

Best regards
Michael

On Dec 6, 2006, at 1:43 PM, Magnus Westerlund wrote:

> Hi,
>
> I was doing my AD eval of the SCTP AUTH draft and have a few  
> question and comments.
>
> understand that both end-points do not have each others random  
> value. However if one has a shared secret prior, having the INIT  
> being signed by RANDOM|KEY and the INIT ACK being signed with the  
> full key as the peer will return his random value in the INIT ack  
> would allow that even the establishment to be signed. Thus  
> preventing MITM attacks on algorithm choice. It would also allow a  
> SCTP end-point to only create associations from trusted peers.
The SCTP base spec requires that INIT, INIT-ACK and SHUTDOWN-COMPLETE  
are not bundled. Since
the usage of SCTP-AUTH requires bundling of the AUTH chunks these  
chunks can not be autenticated.

However, a server can restrict its association to client which have a  
shared secret. To do
this the server must require the authentication of the COOKIE-ECHO  
chunk. Wheet containing one or more DATA chunks
>>    with a SHUTDOWN chunk and restart the T2-shutdown timer.  If a
>>    SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
>>    chunks (i.e., there are TSNs that can be acknowledged that are larger
>>    than the cumulative TSN, and thus gaps exist in the TSN sequence), or
>>    if duplicate TSNs have been received, then a SACK chunk MUST also be
>>    sent.
>>
>> While Section 6.2 says the SHUTDOWN "MAY" be used, section 9.2 says that
>> SHUTDOWN "MUST" be used.  Section 9.2 also mandates a "MUST" for a SACK, while
>> the Note in Section 6.2 only says "should".
>>
>> It would probably better for Section 6.2 to point to Section 9.2 for the correct
>> behavior.
>>
>> Something like:
>>
>>    Acknowledegments MUST be sent in SACK chunks unless shutdown was
>>    requested by the ULP, in which case Section 9.2 describes the proper
>>    response.
>>
>> And remove the Note.
>>
>> -vlad
>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Dec 2006 15:46:22 +0100

Hi Magnus,

see my comments in-line.

Best regards
Michael

However, a server can restrict its association to client which have a  
shared secret. To do
this the server must require the authentication of the COOKIE-ECHO  
chunk. When the server
receives the INIT it just responds with an INIT-ACK and does not  
change its state. If
the AUTH; COOKIE-ECHO packet is received the association only changes  
from CLOSED to ESTABLISHED
when the authentication is successful. So you get what you want on  
the server side.
> I don't understand what "lifetime of the endpoint" actually means.  
> Is it meaning as long as this host does not replace its OS, until  
> it reboots the next time, or what?
>
An SCTP endpoint is a list of IP-addresses and a port number. It is  
"one end of associations".
For the one-to-many style API it is a socket.
So it is not the stack or the OS.
> First of all I don't think using the complete string as a number  
> was a particular bright idea, due to the issues of comparing them  
> as numbers. I would have preferred that one first looked at the  
> length and then the value. That way one could have started  
> comparing the most significant word that your architecture  
> supported. But with the added requirement that the RANDOM parameter  
> value always is 32 bytes I don't see that is has any real impact.
>
But even when you first look at the lengths, the important point is  
that both sides
to the same comparison. SO you need something like "smaller as  
numbers in network byte order".
> At least when I come to this paragraph, I was missing some context.  
> I had a hard time understanding if the above text was something  
> general or applying to a particular case. After having read on and  
> thought about it I do realize that it applies to the particular  
> case when sending a cookie echo. Can you please include some  
> introductory sentences that explain in which context the above  
> applies.
OK, what about having at the beginning:
When an endpoint requires COOKIE-ECHO chunks to be authenticated some
special procedures have to be followed because the reception of an
COOKIE-ECHO chunk might result in the creation of an SCTP association.
> Please correct language is above, missing "is" before discarded.
Sure.
> Sorry for being dense, but why does not the restart procedure work?  
> Are you assuming that a end-point having ben the server
receives the INIT it just responds with an INIT-ACK and does not  
change its state. If
the AUTH; COOKIE-ECHO packet is received the association only changes  
from CLOSED to ESTABLISHED
when the authentication is successful. So you get what you want on  
the server side.
> I don't understand what "lifetime of the endpoint" actually means.  
> Is it meaning as long as this host does not replace its OS, until  
> it reboots the next time, or what?
>
An SCTP endpoint is a list of IP-addresses and a port number. It is  
"one end of associations".
For the one-to-many style API it is a socket.
So it is not the stack or the OS.
> First of all I don't think using the complete string as a number  
> was a particular bright idea, due to the issues of comparing them  
> as numbers. I would have preferred that one first looked at the  
> length and then the value. That way one could have started  
> comparing the most significant word that your architecture  
> supported. But with the added requirement that the RANDOM parameter  
> value always is 32 bytes I don't see that is has any real impact.
>
But even when you first look at the lengths, the important point is  
that both sides
to the same comparison. SO you need something like "smaller as  
numbers in network byte order".
> At least when I come to this paragraph, I was missing some context.  
> I had a hard time understanding if the above text was something  
> general or applying to a particular case. After having read on and  
> thought about it I do realize that it applies to the particular  
> case when sending a cookie echo. Can you please include some  
> introductory sentences that explain in which context the above  
> applies.
OK, what about having at the beginning:
When an endpoint requires COOKIE-ECHO chunks to be authenticated some
special procedures have to be followed because the reception of an
COOKIE-ECHO chunk might result in the creation of an SCTP association.
> Please correct language is above, missing "is" before discarded.
Sure.
> Sorry for being dense, but why does not the restart procedure work?  
> Are you assuming that a end-point having being restarted will have  
> lost the RANDOM values associated with the association that existed  
> prior to the peer restarting?
The restarted endpoint will chose (most likely) a different random  
number than before.
So if he will send the AUTH; COOKIE_ECHO packet he uses (most likely)  
a different random number
the receiver uses to verify the authentication.

Please note that this behaviour is important and intended. This means  
that if an attacker can take
over the IP-address he still can not take over the association by  
performing a restart.
>
>
> It would be good if you would update the document after having  
> resolved the discussion points above.
I have (up to now) identified to text changes which are described  
above. Do they resolve
all your issues?
> IETF Transport Area Director & TSVWG Chair

ing restarted will have  
> lost the RANDOM values associated with the association that existed  
> prior to the peer restarting?
The restarted endpoint will chose (most likely) a different random  
number than before.
So if he will send the AUTH; COOKIE_ECHO packet he uses (most likely)  
a different random number
the receiver uses to verify the authentication.

Please note that this behaviour is important and intended. This means  
that if an attacker can take
over the IP-address he still can not take over the association by  
performing a restart.
>
>
> It would be good if you would update the document after having  
> resolved the discussion points above.
I have (up to now) identified to text changes which are described  
above. Do they resolve
all your issues?

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Dec 2006 16:22:32 +0100

Thanks for the quick response.

See inline for response.

> when the authentication is successful. So you get what you want on  

Okay, thanks for explanation. I think there might be some benefit in 
including some explanation about this and the possibilities COOKIE_ECHO 
provide. I think it is quite an important thing that should be clear and 
included in the security consideration. As it provide a security level a 
server can select to use or not.

So if a MITM changes the HMAC-ALGO it can do nothing more than restrict 
the list to SHA-1. But there are no protection against this if I 
understand correctly.

And a MITM can't touch the CHUNKS parameter because that would result in 
association failure when a chunk requested to be authenticated is not.

> So it is not the stack or the OS.

So what you are saying is that for the life time of the application 
using a particular port on any of its interfaces is shall not change the 
HMAC-ALGO list. That sounds about right. No change needed.

>>    result is thesociation shared key."
>>

Agreed. And under the current restrictions the issue I saw does not 
really exist, as you can implement the algorithm I proposed and still be 
compliant with the above text. Thus I don't see any need for a change here.

> COOKIE-ECHO chunk might result in the creation of an SCTP association.

That is fine, please add it.

> over the IP-address he still can not take over the association by  

Here I think there is need to point out that feature. Otherwise people 
may only see the issues with authenticating COOKIE_ECHO and not all the 
benefits and select to not use it.

Please propose some text for both this location and the security 
consideration.

Cheers

Magnus Westerlund

---

From: "Meyknecht, Bernward" <[email-masked]>
Date: Wed, 6 Dec 2006 16:35:50 +0100

Hi Michael,

a question concerning your 'AUTH; COOKIE-ECHO' packet, that you mention below:
RFC's 2960 and 4460 clearly state that:
Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
(e.g., here from 4460)

Didn't read the details from the AUTH draft, do we state there, that this 
rule from above does not apply here and has to be ignored by the receiver
of an COOKIE-ECHO, (only) if both peers have confirmed support for AUTH 
via supported chunks type parameter (or something similar)?
Other receivers may ignore the whole packet when finding something before
the COOKIE-ECHO.

Best regards,

Bernward

RFC 2960 says:
Note: The COOKIE ECHO chunk can be bundled with any pending
      outbound DATA chunks, but it MUST be the first chunk in the packet
      and until the COOKIE ACK is returned the sender MUST NOT send any
      other packets to the peer.

-----Ursprüngliche Nachricht-----
Von: Michael Tuexen [mailto:[email-masked]] 
Gesendet: Mittwoch, 6. Dezember 2006 15:46
An: Magnus Westerlund
Cc: Randall Stewart; tsvwg; EKR; Peter Lei (peterlei)
Betreff: Re: [Tsvwg] AD evaluation comments on draft-ietf-tsvwg-sctp-auth-06

Hi Magnus,

see my comments in-line.

Best regards
Michael

Sure.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 7 Dec 2006 11:06:44 +0100

Hi Bernward,

see my comments in-line.

Best regards
Michael

> via supported chunks type parameter (or something similar)?
The COOKIE-ECHO will only be authenticated if the receiver supported the
AUTH chunk and normally even only if the receiver of the COOKIE-ECHO has
requested to received it in an authenticated way. There is special text
in the SCTP-AUTH document which describes the handling of a packet  
containing
the AUTH chunk as first one, the COOKIE-ECHO chunk as the second one and
possibly more chunks after that.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 7 Dec 2006 11:34:48 +0100

Hi Magnus,

comments in-line.

Best regards
Michael

On Dec 6, 2006, at 4:22 PM, Magnus Westerlund wrote:

>>> 1. Are there a good reason for not signing INIT and INIT-ACK? I  
>>> do  understand that both end-points do not have each others  
>>> random  value. However if one has a shared secret prior, having  
>>> the INIT  being signed by RANDOM|KEY and the INIT ACK being  
>>> signed with the  full key as the peer will return his random  
>>> value in the INIT ack  would allow that even the establishment to  
>>> be signed. Thus  preventing MITM attacks on algorithm choice. It  
>>> would also allow a  SCTP end-point to only create associations  
>>> from trusted peers.
>> The SCTP base spec requires that INIT, INIT-ACK and SHUTDOWN- 
>> COMPLETE  are not bundled. Since
>> However, a server can restrict its association to client which  
>> have a  shared secret. To do
>> this the server must require the authentication of the COOKIE- 
>> ECHO  chunk. When the server
>> the AUTH; COOKIE-ECHO packet is received the association only  
>> changes  from CLOSED to ESTABLISHED
>> when the authentication is successful. So you get what you want  
>> on  the server side.
>
> Okay, thanks for explanation. I think there might be some benefit  
> in including some explanation about this and the possibilities  
> COOKIE_ECHO provide. I think it is quite an important thing that  
> should be clear and included in the security consideration. As it  
> provide a security level a server can select to use or not.
So we can add after:
    Requiring ABORT chunks and COOKIE-ECHO chunks to be authenticated
    makes it impossible for an attacker to bring down or restart an
    association as long as the attacker does not know an association
    shared key.  But 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-ECHO chunks only in an authenticated way, the restart
    procedure does not work.
the following two sentences:
   If a server has an endpoint pair shared key with some clients it can
   request the COOKIE_ECHO chunk to be authenticated and can ensure that
   only associations from client with a correct endpoint pair shared key
   are accepted.
>
> So if a MITM changes the HMAC-ALGO it can do nothing more than  
> restrict the list to SHA-1. But there are no protection against  
> this if I understand correctly.
>
> And a MITM can't touch the CHUNKS parameter because that would  
> result in association failure when a chunk requested to be  
> authenticated is not.
The last two things were true before the last revision of the  
document. Now the list of chunks and the
list of hmac algorithm identifiers is included in the computation of  
the association shared secret.
So f the MITM would change something, the association shared secrets  
are not the same and the
authenticated chunks will be discarded.
>>> I don't understand what "lifetime of the endpoint" actually  
>>> means.  Is it meaning as long as this host does not replace its  
>>> OS, until  it reboots the next time, or what?
>>>
>> An SCTP endpoint is a list of IP-addresses and a port number. It  
>> is  "one end of associations".
> using a particular port on any of its interfaces is shall not  
> change the HMAC-ALGO list. That sounds about right. No change needed.
>
>>> 3. Section 6.1:
>>>
>>> was a particular bright idea, due to the issues of comparing  
>>> them  as numbers. I would have preferred that one first looked at  
>>> the  length and then the value. That way one could have started   
>>> supported. But with the added requirement that the RANDOM  
>>> parameter  value always is 32 bytes I don't see that is has any  
>>> real impact.
>>>
>> But even when you first look at the lengths, the important point  
>> is  that both sides
> really exist, as you can implement the algorithm I proposed and  
> still be compliant with the above text. Thus I don't see any need  
> for a change here.
>
>>> 4. Section 6.3
>>> At least when I come to this paragraph, I was missing some  
>>> context.  I had a hard time understanding if the above text was  
>>> something  general or applying to a particular case. After having  
>>> read on and  thought about it I do realize that it applies to the  
>>> particular  case when sending a cookie echo. Can you please  
>>> include some  introductory sentences that explain in which  
>>> context the above  applies.
Done.
>>> Sorry for being dense, but why does not the restart procedure  
>>> work?  Are you assuming that a end-point having being restarted  
>>> will have  lost the RANDOM values associated with the association  
>>> that existed  prior to the peer restarting?
>> The restarted endpoint will chose (most likely) a different  
>> random  number than before.
>> So if he will send the AUTH; COOKIE_ECHO packet he uses (most  
>> likely)  a different random number
>> Please note that this behaviour is important and intended. This  
>> means  that if an attacker can take
> Here I think there is need to point out that feature. Otherwise  
> people may only see the issues with authenticating COOKIE_ECHO and  
> not all the benefits and select to not use it.
>
So what about replacing
<t>Requiring ABORT chunks and COOKIE-ECHO chunks to be authenticated
makes it impossible for an attacker to bring down or restart an  
association as
long as the attacker does not know an association shared key. But 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-ECHO chunks only in an authenticated way,
the restart procedure does not work.</t>

by

<t>Requiring ABORT chunks and COOKIE-ECHO chunks to be authenticated
makes it impossible for an attacker to bring down or restart an  
association as
long as the attacker does not know an association shared key. But 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-ECHO chunks only in an authenticated way,
the restart procedure does not work, because the restarting end-point  
does not
know the association shared key of the old association to be  
restarted.</t>

And for the security considerations:

<t>When an endpoint accepts COOKIE-ECHO chunks only in an  
authenticated way
the restart procedure does not work. Neither an attacker which does  
not know the
association shared key can perform it nor an restarted endpoint can  
restart
the association.</t>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 07 Dec 2006 16:21:48 +0100

>    only associations from client with a correct endpoint pair shared key

Seems okay.

> authenticated chunks will be discarded.

Okay, sorry for being dense.

[snip]
> association shared key can perform it nor an restarted endpoint can  

The last sentence is kind of hard to understand.

When an endpoint requires COOKIE-ECHO chunks to be authenticated the 
restart procedure does not work. This include both a restarted endpoint 
that knows the shared key, and an attacker not knowing the shared key.

Also isn't there a way of making the restart process to work? If I as an 
endpoint write the "random" values for both end-points to permanent 
storage. That way I can recover the necessary state to restart. If that 
works shouldn't we clarify this.

Cheers

Magnus Westerlund