Subject: [Tsvwg] sctp-auth questions

From: Vlad Yasevich <[email-masked]>
Date: Wed, 11 Jul 2007 12:17:02 -0400

Hi

I was going through the 08 draft and planning for the implementation
and had some questions.

Section 6.1 states:

>    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 there is no problem in case of INIT
>    collision.

Lifetime of what?  Association, endpoint?

Section 6.2 states:

>    If the endpoint has no endpoint pair shared key for the peer, it MUST
>    use Shared Key Identifier 0 with an empty endpoint pair shared key.
>    If there are multiple endpoint shared keys the sender selects one and
>    uses the corresponding Shared Key Identifier.

The phrase of "endpoint pair shared key for the peer" gives an impression that
each peer of the sctp endpoint can have it's own set of shared keys.  As an
example:  a single endpoint may be used to connect to different systems and has
a specific shared key for each system.  This is somewhat misleading.  All the
keys really belong to the endpoint and it's up to the ULP (userspace) to specify
which key to use.  I would suggest that "for the peer" be deleted.

Section 6.3
> The out of the blue handling MUST be
>    based on the packet without taking the AUTH chunk into account.

What is this requirement supposed to refer to?

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

If the receiver requires ABORT chunks to be authenticated, wouldn't OOTB
ABORTS be dropped?

Thanks
-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Jul 2007 18:44:53 +0200

Hi Vlan,

see my comments in-line.

Best regards
Michael

> Lifetime of what?  Association, endpoint?
End-point.
> which key to use.  I would suggest that "for the peer" be deleted.
I'm not sure what you mean... The shared keys are for end-point  
pairs. So if you
have one end-point (lets say a 1-to-many style socket), you can have  
different end-point
pair shared keys for each peer. That is why you have an sca_assoc_id  
in the
SCTP_AUTH_KEY socket option.

So I think the text is correct.
> What is this requirement supposed to refer to?
No ABORT in response to a packet which contains AUTH;ABORT, for example.
> If the receiver requires ABORT chunks to be authenticated, wouldn't  
Yes, that is why it may take longer to figure out that your peer died.

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 11 Jul 2007 12:57:31 -0400

>> Lifetime of what?  Association, endpoint?

Can that be put the draft.  The last sentence is incomplete.

> I'm not sure what you mean... The shared keys are for end-point pairs.
> So if you
> pair shared keys for each peer. That is why you have an sca_assoc_id in the

Well, the endpoint doesn't know which of it's keys is which peer.   All it has
is a list keys it knows.  The API specifies which key to use.

BTW, having an ancillary data option to specify the key id along with the sendmsg
might also be useful, but that's a topic for the API spec.

Saying "shared for the peer" give an impression that there is knowledge that
specific keys apply to specific peers, while there isn't such thing.

> No ABORT in response to a packet which contains AUTH;ABORT, for example.

Ah.  That's not really clear in that particular section.  Any way to clear
it up.

> Yes, that is why it may take longer to figure out that your peer died.

Ok.  Any way to add this example in?

Thanks
-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Jul 2007 19:11:54 +0200

> Can that be put the draft.  The last sentence is incomplete.
RFC 4895 will read:

    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.

Please note that the document is in AUTH48 and we are waiting for the
last author to give his final OK...
>>> keys really belong to the endpoint and it's up to the ULP  
>>> (userspace)
>>> to specify
>> pairs.
The list of endpoint pair keys is something you would keep on the  
STCB. It
is per association. You can set it for an end-point and it is then the
default for all new associations, but this is "an end-point pair" =  
association
thing.
> Ah.  That's not really clear in that particular section.  Any way  
As said earlier: The last call was a sometime ago...
The final text is:

    If the receiver does not find an STCB for a packet containing an  
AUTH
    chunk as the first chunk and does not find a COOKIE-ECHO chunk as  
the
    second chunk, it MUST use the chunks after the AUTH chunk to look up
    an existing association.  If no association is found, the packet  
MUST
    be considered as out of the blue.  The out of the blue handling MUST
    be based on the packet without taking the AUTH chunk into account.
    If an association is found, it MUST process the AUTH chunk using the
    STCB from the existing association as described earlier.

> Ok.  Any way to add this example in?
No, I do not think so.

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 11 Jul 2007 13:31:07 -0400

> last author to give his final OK...

OK.

>> Ok.  Any way to add this example in?

Bummer.

Thanks
-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 11 Jul 2007 14:41:49 -0400

Peter Lei wrote:
> Right.  The set of shared keys that are set on the endpoint is
> the default set of shared keys on every association that is created
> on that endpoint; this behaves like most of the socket options.
> You can have different shared keys on a per assoc basis by using
> the API's assoc_id field to set/delete shared keys after the assoc
> is formed.

Right, the set of shared keys for an association may be different
from that for an endpoint.  However, the text in the spec talks about
the endpoint.  There is really no peer information in the endpoint,
and speaking about keys for a peer is misleading in my opinion.

> 
> This should not be confused with the actual keying material used for
> the AUTH HMAC mechanism itself, the concatenated keys, which must
> be kept on a per assoc basis since the RANDOM params are part of
> those keys (along with the HMAC_ID and CHUNKS params contents).

Nope, not confusing those.

> I disagree with this... why would you want/need to send individual
> SCTP messages on the same association with different keys?
>
Not the same association, but a 1-to-many endpoint.  Let's say you have
3 different keys on the endpoint.  Each association on that endpoint
would have 3 keys as well with a keying material vector for each key. 
You can then specify a different keys to use as part of sendmsg().

Another time this would be useful if when restarting with authenticated
cookie-echo chunks.  The application can issue a sendmsg() stating which
key should be used.  The restart procedure then wouldn't have to do anything
special.

-vlad

---

From: Peter Lei <[email-masked]>
Date: Wed, 11 Jul 2007 13:21:23 -0500

Some comments in-line:

Michael Tuexen wrote:
> The list of endpoint pair keys is something you would keep on the STCB. It

--peter

>    If the receiver does not find an STCB for a packet containing an AUTH
>    chunk as the first chunk and does not find a COOKIE-ECHO chunk as the
>    an existing association.  If no association is found, the packet MUST

---

From: Peter Lei <[email-masked]>
Date: Wed, 11 Jul 2007 13:57:33 -0500

> You can then specify a different keys to use as part of sendmsg().

You can set the active shared key to use on a per assoc basis (via
socket options)-- you can basically add and delete shared keys and
set the active shared key on an assoc basis and I believe you can
achieve the above without needing ancillary data.  Note this also
works for 1-to-many sockets.

> key should be used.  The restart procedure then wouldn't have to do anything

Associations cannot restart if you authenticate cookie-echo chunks
since the restarting side's new assoc will have picked a new random
parameter and might (though probably not likely) have a different
set of chunks and/or hmac ids listed.  Only the shared keys are set
by the user, not the random parameter contents.

--peter

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 11 Jul 2007 15:58:57 -0400

> works for 1-to-many sockets.

Yes, I now, but it's awkward to do this with socket options, if you don't
want to delete keys.

Calling setsockopt() before a send is annoying if you want to change keys.

> by the user, not the random parameter contents.

Just re-read the spec and can see how this wouldn't really work.  

What I don't understand now is how exactly the following text applies:

>                                                            In
>    case of INIT collision, the rules governing the handling of this
>    random number follow the same pattern as those for the Verification
>    Tag, as explained in section 5.2.4 of RFC2960 [5].

Does this mean that in addition to Vtag comparison in step 3, random
numbers must be compared as well?

Just checking since it's not clear.

Thanks
-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Jul 2007 22:27:14 +0200

On Jul 11, 2007, at 9:58 PM, Vlad Yasevich wrote:

> Peter Lei wrote:
>> Vlad Yasevich wrote:
>>
>>>>>> BTW, having an ancillary data option to specify the key id  
>>>>>> along with
>>>>>> the sendmsg
I do not think that you want to change the key for an association for
each send() call. At I do not see an application for that (right now).
So I think using the setsockopt for this is appropriate.
> numbers must be compared as well?
In the processing of the INIT collision case you have already code
to decide which v-tags are used. You apply the same algorithm to
decide which random numbers are used.
> Just checking since it's not clear.
What exactly is not clear?

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 11 Jul 2007 16:48:11 -0400

Michael Tuexen wrote:
>>>>>>> BTW, having an ancillary data option to specify the key id along
>>>>>>> with
>>>>>>> the sendmsg

Ok, I was an idea, and I'll drop it if it not useful.

> What exactly is not clear?

Well, for one,  the section that's describing INIT collisions is 5.2.1.
If that's the section that should be referenced, then things clear up.

If 5.2.4 is the right section (Handle a COOKIE ECHO when a TCB exists),
then specifying specifics for random number comparison is necessary, IMO.

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Jul 2007 23:19:54 +0200

On Jul 11, 2007, at 10:48 PM, Vlad Yasevich wrote:

>>>>>>>> along
You do not use the random numbers to figure out which Action/Description
applies. You just use the tags for that. You select the random numbers
like you do it for the v-tags. So no comparisons for the random numbers
are necessary.

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 12 Jul 2007 09:36:47 -0400

Hi Michael

> like you do it for the v-tags. So no comparisons for the random numbers

I am probably being really dense here, but it still not clear what particular
item from 2960 Section 5.2.4 applies.

The statement from draft-sctp-auth is:
   In case of INIT collision, the rules governing the handling of this
   random number follow the same pattern as those for the Verification
   Tag, as explained in section 5.2.4 of RFC2960 [5].  Therefore each
   endpoint knows its own random number and the peer's random number
   after the association has been established.

Now, section 5.2.4 is fairly long and has multiple rules that describe
handling of verification tags.

Rule 3 from that section mentions comparison of the tag carried by the
cookie to the association v-tag.

Rule 5 (table) specifies tag and tie-tag comparisons (my guess is this doesn't apply).

Action B specifies the handling of V-TAG during simultaneous start (this is probably
what's referred to in the auth spec)

So, is Action B what's being referred to by the paragraph in sctp-auth?
If yes, that could be made clearer.

Thanks
-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 12 Jul 2007 16:55:57 +0200

Hi Vlad,

let me describe this in a different way:

Both INIT and the INIT-ACK chunks contain Initiate Tags, just like
the RANDOM parameters. RFC 2960 describes how you handle the case
where you receive these chunk in an "unexpected" state. The result
is that both sides use on Initiate Tag. For SCTP-AUTH you should
use the same mechanism for the the RANDOM parameter as for the
initiate tag. Once you decide which Initiate Tag you use, you
know that you use the RANDOM parameter of the chunk containing
that Initiate Tag.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Thu, 12 Jul 2007 11:10:18 -0400

> know that you use the RANDOM parameter of the chunk containing

Let me just add one thing.. that might help too.

Basically Vlad when the tie-tags match and you would
accept the association.. (replacing what was in
your INIT since we are talking about the collision
case here) and use the tags in the cookie.. then
you would use the random parameters from that cookie.

R

>> So, is Action B what's being referred to by the paragraph in sctp- auth?

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 12 Jul 2007 11:18:49 -0400

> you would use the random parameters from that cookie.

OK.  So basically the handling of the Random parameter is the
same as behavior for Verification TAg as describe in Action B of
section 5.2.4.

That make it absolutely clear, thanks.  The wording in the spec
was not that clear.

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 18 Jul 2007 15:48:56 -0400

Hi All

One more item from Draft 8:

Section 3.1

   The RANDOM parameter MUST be included once in the INIT or INIT-ACK
   chunk if the sender wants to send or receive authenticated chunks to
   provide a 32 byte Random Number.

The sentence reads almost like a run-on and I can't quite figure out
what "to provide a 32 byte Random Number" is trying to explain.
The first time I read it, I though it was part of the requirement, but
I don't think it was meant to be.

I this this sentence needs to clarified.

Thanks
-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 18 Jul 2007 15:55:54 -0400

> I don't think it was meant to be.

Ok, so it is meant to be a requirement (based on section 6.1), but it
is worded badly.

Still needs to be reworded.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Jul 2007 14:18:30 -0600

Vlad,

It should obviously be interpreted so:

Section 3.1

   The RANDOM parameter MUST be included once in the INIT or INIT-ACK
   chunk (if the sender wants to send or receive authenticated chunks) to
   provide a 32 byte Random Number.

That is,

   "to provide a 32 byte Random Number"

is the purpose of including the RANDOM parameter.  And,

   "if the sender wants to send or receive authenticated chunks"

modifies the MUST in that the RANDOM parameter does not need to be included
in all INIT or INIT-ACK messages, only when the sender wants to send or
receive authenticated chunks.

--brian

Vlad Yasevich wrote:                             (Wed, 18 Jul 2007 15:55:54)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 18 Jul 2007 16:37:17 -0400

>    provide a 32 byte Random Number.

Sorry, but I don't see the parenthesis in the on-line copy.

Either parenthesis or commas would clear it up.

-vlad

---

From: Christopher Benson <[email-masked]>
Date: Wed, 18 Jul 2007 13:37:25 -0700 (PDT)

Vlad and authors,

How about rephrasing as:
    If the sender of an INIT or INIT-ACK wants to send or 
    receive authenticated chunks, then the RANDOM parameter 
    MUST be included [once] to provide a 32 byte Random 
    Number [as the RANDOM parameter's value].

I think that is the intention and it is clearer to me.
The [once] may be dropped in my opinion, and I added a 
perhaps superfluous phrase connecting the value and the 
parameter.

 With thanks, from Chris Benson.

On Wed, 18 Jul 2007, Vlad Yasevich wrote:

>>  Date: Wed, 18 Jul 2007 15:55:54 -0400
>>  From: Vlad Yasevich <[email-masked]>
>>  To: tsvwg <[email-masked]>
>>  Cc: Michael Tuexen <[email-masked]>,
>>       Randall Stewart <[email-masked]>
>>  Subject: [Tsvwg] Re: sctp-auth questions
>>  
>>  Vlad Yasevich wrote:
>>  > Hi All
>>  >

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 18 Jul 2007 16:49:46 -0400

Hi Chris

>     Number [as the RANDOM parameter's value].

I would go even as far as to completely kill this reference to
32 bytes.  Section 6.1 already has a hard requirement on
the RANDOM number being 32 bytes long and having it in multple
places just confuses things.

Just my $.02.

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 18 Jul 2007 23:28:16 +0200

Dear all,

the ID is currently in AUTH48, which means that it is
unfortunately too late to include these changes.

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jul 2007 16:55:41 -0700

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jul 2007 16:56:55 -0700

Sorry - meant to say that you might ask the RFC-Editor whether such a
change would be OK.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 19 Jul 2007 02:46:30 +0200

ADs?

On Jul 19, 2007, at 1:56 AM, Joe Touch wrote:

>>>>>>> The first time I read it, I though it was part of the  
>>>>>>> requirement,
>>>>>>> but

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Jul 2007 07:16:18 +0300

If the authors feel that this is a clarification, it is appropriate  
to make this change during AUTH48.

(I wish the document had received this level of review during the WGLC.)

>> Sorry - meant to say that you might ask the RFC-Editor whether such a

Lars

---

From: Randall Stewart <[email-masked]>
Date: Thu, 19 Jul 2007 06:45:19 -0400

> Sorry - meant to say that you might ask the RFC-Editor whether such a

It is just a textual clearfication... " a edit " :-)

Michael, why don't you send a request to the RFC editor
about this.. most they can do is say no :-D

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 19 Jul 2007 06:47:49 -0400

Lars Eggert wrote:
> If the authors feel that this is a clarification, it is appropriate  to 
> make this change during AUTH48.
> 

I think it is worth the change.. but I definetly agree with you.. it
would have been nice to get these comments BEFORE we were in
auth-48.. like WGLC :-0

R

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 19 Jul 2007 13:51:06 +0200

Hi Randy,

I'll send a note. I'll also look what Vlad had posted before.

Best regards
Michael