OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (AMQP-139) Link recovery tokens

    [ https://issues.oasis-open.org/browse/AMQP-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68263#comment-68263 ] 

Rob Godfrey commented on AMQP-139:

The other alternative would be to associate the recovery token at the container level, and to exchange the tokens in the open frames (the spoofing issue being that links are identified by the two container ids and the name of the link, but nowhere do we assert the link between the use of a container-id and any sort of authentication context).  Even without the link recovery issue, the semantics associated with sole connection detection (https://www.oasis-open.org/committees/download.php/61724/amqp-soleconn-v1.0-wd03.pdf) would allow what amounts to DoS attacks on other clients simply by knowing the container id they chose.  

One issue with the use of dynamically generated tokens is that it requires the client to have local storage (available wherever it restarts).  Where a (non anonymous) authentication has taken place at the connection level this could be used to validate the container id used (either by some defined mechanism associating container-ids with authentication identities, or simply associating the container-ids on a first-come-first-served basis and the server storing this association for some defined period of time). 

> Link recovery tokens
> --------------------
>                 Key: AMQP-139
>                 URL: https://issues.oasis-open.org/browse/AMQP-139
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Improvement
>          Components: Security
>            Reporter: Clemens Vasters
> The recovery of links from broken connections/sessions may require proof that the client is authorized to perform that recovery. In this scenario, the client may be a failover instance of a prior client instance. What shall be prevented is that some other party that has access to the broker and that can guess the respective link names, can "steal" such recovery-pending links from another party that has just lost its connection to the broker. 

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]