Subject: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC 4895

From: Shweta r <[email-masked]>
Date: Tue, 5 Jun 2018 06:35:20 +0000

Hi Group,

Greetings. I have a doubt regarding SCTP RFC 4895.

1)      section "3.1.  Random Parameter (RANDOM)".

      Random Number: n bytes (unsigned integer)
      This value represents an arbitrary Random Number in network byte order.

     Section 6.1.  Establishment of an Association Shared Key

    An SCTP endpoint willing to receive or send authenticated chunks MUST
    send one RANDOM parameter in its INIT or INIT-ACK chunk.  The RANDOM
    parameter MUST contain a 32-byte Random Number.

----> The random of size 32 bytes should be in network byte order means 32bytes is divided into 4 bytes partition (totally 8 partitions) and then ntohl is done for each partition ?

2)      Peer has asked for HB authentication.

In the scenario of sending HB to unconfirmed address, is it correct to bundle AUTH+HB and send to unconfirmed address ?

My doubt here is can AUTH be sent to unconfirmed address ?

3)      In 4985, it is given,

Local (auth support)                                                      Peer (Auth not support)

Send INIT with auth para and chunklist(DATA) -->

                                                                        <-----  sends INIT-ACK without auth parameters  (as per above section,  Peer ignore auth parameter received in INIT and sends INIT-ACK)

Cookie echo                                                   --->

                                                                      <----     cookie ack

                                               Association established.

                                                                     <----   sends DATA without AUTH chunk

Local should send SACK or discard the DATA as it does not have AUTH ?

4)      6.1.  Establishment of an Association Shared Key

    The concatenation is performed on byte vectors, and all numerical
   comparisons use network byte order to convert the key vectors to a number.

---->Can you please explain about how to convert key vector to a number and what should be the size of this number.

5)      What should be the length of  Association Shared Key ?  (As per RFC 2104 , the key can be of any length upto 64 bytes)

6)      For client SHA-1 most preferable

For server SHA-256 most preferable

       SCTP Client                                             SCTP Server

INIT send with (SHA-1, SHA-256)  ---->

                                                     <----   INIT Ack ( SHA-256, SHA-1)

Cookie                                         --->

                                                    <---  cookie ack

                                                    <--- sends DATA with  AUTH chunk HMAC Identifier= SHA-1

      Send SACK with AUTH chunk hmac id = SHA-256 ---->

         DATA & SACK processing should be success , this is my understanding.

        What is your opinion?

________________________________

Regards,
Shweta K R
Tester - VPP, 2012 LAB

Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066
Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email: [email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Jun 2018 14:54:25 -0400

> On 5. Jun 2018, at 02:35, Shweta r <[email-masked]> wrote:
> 
> Hi Group,
>  
> 1)      section “3.1.  Random Parameter (RANDOM)”.
>  
No. It is just a number of 32 bytes and is stored in big enadian. 
> My doubt here is can AUTH be sent to unconfirmed address ?
Yes. If the peer requires HEARTBEAT chunks to be authenticated, the end-point
has to sent them authenticated. It does not matter whether the HERTBEATs are
used for path confirmation or not.
> Local should send SACK or discard the DATA as it does not have AUTH ?
After thinking about it and discussing it with Peter Lei, the local node must
drop the DATA chunk.
> ---->Can you please explain about how to convert key vector to a number and what should be the size of this number.
The point is to compare the byte vector from the most significant byte to the lowest.
That is why you need to know the byte ordering.
> 5)      What should be the length of  Association Shared Key ?  (As per RFC 2104 , the key can be of any length upto 64 bytes)
It can be arbitrarily long. See
https://tools.ietf.org/html/rfc6458#section-8.3.3
for an API. Please note the in the case of DTLS/SCTP it is 64 bytes as specified in
https://tools.ietf.org/html/rfc6083#section-4.8
>          DATA & SACK processing should be success , this is my understanding.
I agree.

Please let us know if you have further questions.

Best regards
Michael
> Tester – VPP, 2012 LAB

---

From: Shweta r <[email-masked]>
Date: Sat, 9 Jun 2018 13:59:04 +0000

Hi Michael,

Thank you for the reply, which helped us to conclude our points.

1) > 1)      section “3.1.  Random Parameter (RANDOM)”.

--->Does this mean ,when I am using little endian machine, no need of any conversion ?

2) We have doubt regarding shared key id 0
RFC 6083:

4.8.  Handling of Endpoint-Pair Shared Secrets

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.

In RFC 6458:

8.3.3.  Set a Shared Key (SCTP_AUTH_KEY)  

sca_key:  This parameter contains an array of bytes that is to be
      used by the endpoint (or association) as the shared secret key.
      Note that if the length of this field is zero, a null key is set.

---> we want understand what is meaning of empty or Null key. Does this refer to 
1) Length = 0 and no content or
2) Shared secret is filled with all zeros and length is 64.

We have a doubt for generation of Assoc shared key, how to consider this NULL key? Do we concatenate the Other vectors (Local and Remote) to generate the Assoc key as given in RFC 4895, for the Shared key id = 0?

Regards,
Shweta K R
Tester – VPP, 2012 LAB

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: 07 June 2018 00:24
To: Shweta r
Cc: [email-masked]; Sharath Chandra B; Sidhartha pant; Ashutosh prakash
Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC 4895

> My doubt here is can AUTH be sent to unconfirmed address ?
Yes. If the peer requires HEARTBEAT chunks to be authenticated, the end-point has to sent them authenticated. It does not matter whether the HERTBEATs are used for path confirmation or not.
> Local should send SACK or discard the DATA as it does not have AUTH ?
After thinking about it and discussing it with Peter Lei, the local node must drop the DATA chunk.
I agree.

Best regards
Michael
> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield Bengaluru, 
> Karnataka - 560066

---

From: Shweta r <[email-masked]>
Date: Sat, 9 Jun 2018 20:06:46 +0000

Hi Michael,

I have another doubt regarding HMAC algorithm selection.

RFC 4895: 
section 6.1.  Establishment of an Association Shared Key

   Each SCTP endpoint MUST include in the INIT and INIT-ACK a HMAC-ALGO
   parameter containing a list of HMAC Identifiers it requests the peer
   to use.  The receiver of an HMAC-ALGO parameter SHOULD use the first
   listed algorithm it supports.  The HMAC algorithm based on SHA-1 MUST
   be supported and included in the HMAC-ALGO parameter.

Section 6.3.  Receiving Authenticated Chunks

   The receiver MUST use the HMAC algorithm indicated in the HMAC
   Identifier field.  If this algorithm was not specified by the
   receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk
   during association setup, the AUTH chunk and all the chunks after it
   MUST be discarded and an ERROR chunk SHOULD be sent with the error
   cause defined in Section 4.1.

------>           SCTP Client                                             SCTP Server
               INIT send with (SHA-256, SHA-1)  ---->     
                                                      <----   INIT Ack ( SHA-256, SHA-1)
                  Cookie                         --->
                                                  <---  cookie ack
  
                                                 <--- sends DATA  with  AUTH chunk HMAC Identifier= SHA-256
  
           Send SACK with AUTH chunk hmac id = SHA-1 ---->   
  
          DATA & SACK processing should be success , this is my understanding. What is your opinion?

------>           SCTP Client                                             SCTP Server
               INIT send with (SHA-1, SHA-256)  ---->     
                                                      <----   INIT Ack (SHA-1, SHA-256)
                  Cookie                         --->
                                                  <---  cookie ack
  
                                                 <--- sends DATA  with  AUTH chunk HMAC Identifier= SHA-256

          DATA & SACK processing should be success , this is my understanding. What is your opinion?

I got this doubt because in RFC its given " The receiver MUST use the HMAC algorithm indicated in the HMAC Identifier field."

Regards,
Shweta K R
Tester – VPP, 2012 LAB

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: 07 June 2018 00:24
To: Shweta r
Cc: [email-masked]; Sharath Chandra B; Sidhartha pant; Ashutosh prakash
Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC 4895

I agree.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 9 Jun 2018 19:14:54 -0400

> On 9. Jun 2018, at 09:59, Shweta r <[email-masked]> wrote:
> 
> Hi Michael,
> 
It is a random number, so you can consider the byte vector as a number in
network byte order. You don't need to have it in host byte order most of the
time. Only when you are comparisons (greater than or smaller than) you
need to take the byte ordering into account. In FreeBSD we keep it stored
in network byte order all the time.
> We have a doubt for generation of Assoc shared key, how to consider this NULL key? Do we concatenate the Other vectors (Local and Remote) to generate the Assoc key as given in RFC 4895, for the Sha…
When using DTLS/SCTP you use an empty shared key during the initial
handshake. That it 1) of your alternatives.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 9 Jun 2018 19:20:03 -0400

> On 9. Jun 2018, at 16:06, Shweta r <[email-masked]> wrote:
> 
> Hi Michael,
> 
Correct.
>          DATA & SACK processing should be success , this is my understanding. What is your opinion?
Correct.
> I got this doubt because in RFC its given " The receiver MUST use the HMAC algorithm indicated in the HMAC Identifier field."
What is meant is that if the receiver of an auth chunk must use the HMAC algorithm
given in the HMAC Identifier field of the AUTH chunk as long as it is acceptable
by the receiver.

Best regards
Michael

---

From: Shweta r <[email-masked]>
Date: Mon, 18 Jun 2018 05:07:37 +0000

Hi Michael,

Some more doubts.

1) As per my understanding other than DATA & SACK chunks, remaining are control chunks. Am I correct ?

2) As per ,

   5.1.  Authentication Chunk (AUTH)
   The control chunk AUTH MUST NOT appear more than once in an SCTP
   packet.  All control and data chunks that are placed after the AUTH
   chunk in the packet are sent in an authenticated way.  Those chunks
   placed in a packet before the AUTH chunk are not authenticated.
   Please note that DATA chunks can not appear before control chunks in
   an SCTP packet.

   --> As per this, AUTH need not be the first chunk in the packet.
       ERROR+AUTH+DATA is valid combination where peer has asked for only DATA authentication ?

3) Endpoint has asked for only HB authentication. 
   If it receives DATA+AUTH+HB which is not correct because DATA cannot appear before control chunks, whole packet should be discarded.
    What is your opinion?

4)
6.  Procedures
6.1.  Establishment of an Association Shared Key

   An SCTP endpoint has a list of chunks it only accepts if they are
   received in an authenticated way.  This list is included in the INIT
   and INIT-ACK, and MAY be omitted if it is empty.  Since this list
   does not change during the lifetime of the SCTP endpoint there is no
   problem in case of INIT collision.

                                 SCTP Client            SCTP Server
                                  INIT          ---->     
                                                <----   INIT Ack
                                  Cookie        --->
                                                <---  cookie ack
 
                             Restart, send INIT--->

--> During restart all the (random, chunklist, HMAC algo) should be same in INIT chunk ? what should be the behavior if INIT is received with different AUTH params ?

Regards,
Shweta K R
Tester – VPP, 2012 LAB

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: 10 June 2018 04:50
To: Shweta r
Cc: [email-masked]; Sharath Chandra B; Sidhartha pant; Ashutosh prakash
Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC 4895

Correct.
Correct.
> I got this doubt because in RFC its given " The receiver MUST use the HMAC algorithm indicated in the HMAC Identifier field."
What is meant is that if the receiver of an auth chunk must use the HMAC algorithm given in the HMAC Identifier field of the AUTH chunk as long as it is acceptable by the receiver.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 20 Jun 2018 21:28:21 +0200

> On 18. Jun 2018, at 07:07, Shweta r <[email-masked]> wrote:
> 
> 
> 
> Hi Michael,
> 
> Some more doubts.
> 
Only DATA chunks (specified in RFC 4960) and I-DATA (specified in RFC 8260) are
data chunks. All other chunks, including the SACK chunk, are control chunks.
>       ERROR+AUTH+DATA is valid combination where peer has asked for only DATA authentication ?
Yes, that is a valid packet.
>   If it receives DATA+AUTH+HB which is not correct because DATA cannot appear before control chunks, whole packet should be discarded.
We don't require an implementation to pre-scan the packet before processing it. So you
can start with the first chunk, which is a DATA chunk, and process it, since nothing
is wrong with a DATA chunk being the first chunk.
When starting the process the AUTH chunk (or any other control chunk), you detect that
this packet is not valid. You can send an ABORT (possibly indicating a protocol violation)
and destroy the association. This is what the FreeBSD implementation does...
> --> During restart all the (random, chunklist, HMAC algo) should be same in INIT chunk ? what should be the behavior if INIT is received with different AUTH params ?
A restart normally means that the client lost its state completely (like a system rebooted)
so the parameters might not be the same. This is not a collision case...

Best regards
Michael

---

From: Shweta r <[email-masked]>
Date: Thu, 21 Jun 2018 15:33:57 +0000

Hi Michael,

RFC 6083:

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.  Whenever the
   master key changes, a 64-byte shared secret is derived from every
   master secret and provided as a new endpoint-pair shared secret by
   using the exporter described in [RFC5705].  The exporter MUST use the
   label given in Section 5 and no context.  The new Shared Key
   Identifier MUST be the old Shared Key Identifier incremented by 1.
   If the old one is 65535, the new one MUST be 1.

   Before sending the Finished message, the active SCTP-AUTH key MUST be
   switched to the new one.

   Once the corresponding Finished message from the peer has been

   received, the old SCTP-AUTH key SHOULD be removed.

---> My doubt , how user will come to know when to configure new key, Is It like before client sends ChangeCipherSpec, user will get dry_event callback, that time user configures new key and sends Finished message with new key?

     On server side, it should already have updated new key otherwise it cannot process Finished message. But when server (after which packet of DTLS handshake) will update its key ?

Regards,

Shweta K R

Tester – VPP, 2012 LAB

-----Original Message-----

Sent: 21 June 2018 00:58

To: Shweta r

> 1) As per my understanding other than DATA & SACK chunks, remaining are control chunks. Am I correct ?

Only DATA chunks (specified in RFC 4960) and I-DATA (specified in RFC 8260) are data chunks. All other chunks, including the SACK chunk, are control chunks.

>    What is your opinion?

We don't require an implementation to pre-scan the packet before processing it. So you can start with the first chunk, which is a DATA chunk, and process it, since nothing is wrong with a DATA chunk being the first chunk.

When starting the process the AUTH chunk (or any other control chunk), you detect that this packet is not valid. You can send an ABORT (possibly indicating a protocol violation) and destroy the association. This is what the FreeBSD implementation does...

> --> During restart all the (random, chunklist, HMAC algo) should be same in INIT chunk ? what should be the behavior if INIT is received with different AUTH params ?

A restart normally means that the client lost its state completely (like a system rebooted) so the parameters might not be the same. This is not a collision case...

Best regards

Michael

> Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email:

> [email-masked]

> Cc: [email-masked]; Sharath Chandra B; Sidhartha pant; Ashutosh

> prakash

> Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH RFC

> 4895

>>                                                <--- sends DATA  with

>> AUTH chunk HMAC Identifier= SHA-256

>>                                                <--- sends DATA  with

>> AUTH chunk HMAC Identifier= SHA-256

>> Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email:

>> [email-masked]

>> Cc: [email-masked]; Sharath Chandra B; Sidhartha pant; Ashutosh

>> prakash

>> Subject: Re: [tsvwg] Query regarding random parameter in SCTP-AUTH

>> RFC

>> 4895

>> for an API. Please note the in the case of DTLS/SCTP it is 64 bytes

>> as specified in

>>>                                                   <--- sends DATA

>>> with  AUTH chunk HMAC Identifier= SHA-1

>>> Tel: + 91-80-49160700 Ext 71553 II Mob: 9986601255|| Email:

>>> [email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 28 Jun 2018 15:12:11 +0200

> On 21. Jun 2018, at 17:33, Shweta r <[email-masked]> wrote:
> 
> Hi Michael,
>  
>  
>  
> RFC 6083:
Text says when to use a new key for sending: Before sending the Finished message you need to switch.
So the Finished message is the first one using the new AUTH key.
>      On server side, it should already have updated new key otherwise it cannot process Finished message. But when server (after which packet of DTLS handshake) will update its key ?
You should have installed it, but not made it the active one. Therefore you can receive messages using it,
but you don't use it already for sending messages.

Please note the the dance related to the sender dry event is described in section 4.7.

Best regards
Michael