Subject: [xmpp] #53: <abort/> when exceeding SASL retries

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 01:32:19 -0000

#53: <abort/> when exceeding SASL retries
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 6.3.5 states:

 > If there are no remaining mechanisms in its list, the initiating
 > entity SHOULD instead send an <abort/> element to the receiving
 > entity.

 Matthew Wild commented: "As I understand it, <abort/> is used to end an
 in-progress negotiation. However at this point there would be no ongoing
 negotiation, and the server would just needlessly reply with another
 <failure/> without changing any state."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/53>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 18:30:08 -0600

> #53: <abort/> when exceeding SASL retries

What behavior do you recommend instead? It seems that if the client does
not send <abort/> then the server would need to (eventually) time out
the handshake.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Matthew Wild <[email-masked]>
Date: Fri, 25 Jun 2010 13:14:52 +0100

On 25 June 2010 01:30, Peter Saint-Andre <[email-masked]> wrote:
>>  > If there are no remaining mechanisms in its list, the initiating
>>  > entity SHOULD instead send an <abort/> element to the receiving
>>  > entity.
>>

When you say handshake I assume you mean the stream feature
negotiation - my point was that there is no SASL negotiation in
progress (I believe a <failure/> or <success/> to end a negotiation
started with <auth/>) which can be <abort/>ed.

So if the client can't find any acceptable/successful mechanisms I'd
expect it to send a stream error (I'm not sure which) or normal stream
close (does the server need to know the client wasn't happy with what
the server offered it?).

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 15:36:06 -0600

> started with <auth/>) which can be <abort/>ed.

Ah, I see. Your reading of the spec is that:

1. <abort/> can be used only after a mechanism has been agreed upon and
the entities are actively engaged in negotiation of that specific
mechanism (the spec calls this a "handshake", although that term is
undefined).

2. <abort/> cannot be used to end the overall SASL negotiation process.

I'd be fine with that interpretation, and it does simplify handling of
the <abort/> element.

> close (does the server need to know the client wasn't happy with what

I don't see a good stream error condition for this situation because all
of the stream errors are things that would be generated by a server (and
in fact few if any clients ever generate stream errors, although I
suppose they could). Therefore, simply closing the stream seems like the
best approach.

I've clarified the text along these lines.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "xmpp issue tracker" <[email-masked]>
Date: Sun, 27 Jun 2010 21:39:05 -0000

#53: <abort/> when exceeding SASL retries
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/xmpp/trac/ticket/53#comment:1>
xmpp <http://tools.ietf.org/xmpp/>