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

From: Shweta r <[email-masked]>
Date: Mon, 10 Sep 2018 06:45:58 +0000

Hi Michael,

Some doubts :

1)RFC 6083:

During SCTP association establishment, 0 key is used. When master key changes, it becomes 0+1,  so, key 0 should be deleted after FINISHED message from the peer is received ?

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]

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

From: Michael Tuexen [mailto:[email-masked]]

Sent: 28 June 2018 18:42

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

> On 21. Jun 2018, at 17:33, Shweta r <[email-masked]> wrote:

> Hi Michael,

> 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.  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?

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

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

> -----Original Message-----

> From: Michael Tuexen [mailto:[email-masked]]

> Sent: 21 June 2018 00:58

> 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

> > On 18. Jun 2018, at 07:07, Shweta r <[email-masked]> wrote:

> > Hi Michael,

> > Some more doubts.

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

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

> Yes, that is a valid packet.

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

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

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

> 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

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

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

> >> On 9. Jun 2018, at 16:06, Shweta r <[email-masked]> wrote:

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

> > Correct.

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

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

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

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

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

> >>> On 5. Jun 2018, at 02:35, Shweta r <[email-masked]> wrote:

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

> >> No. It is just a number of 32 bytes and is stored in big enadian.

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

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

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

> >> After thinking about it and discussing it with Peter Lei, the local node must drop the DATA chunk.

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

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

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

> >> I agree.

> >> Please let us know if you have further questions.

> >> Best regards

> >> Michael

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