On 8/30/11 2:37 AM, Alexander Holler wrote: > Am 29.08.2011 18:51, schrieb Peter Saint-Andre: >> On 8/25/11 8:57 AM, Alexander Holler wrote: >>> Hello, >>> >>> I have a similiar question as the one before. ;) >>> >>> What should a server do when he receives an<auth/> after a successfull >>> negotiation? >> >> So SASL negotiation is complete but the client or peer server sends new >> SASL<auth/> elements? Why would it do that (other than being buggy)? >> There is no re-authentication option in XMPP. > > Dialback explicit allows it. ;)
Dialback doesn't use the SASL <auth/> element. >>> RFC 6120 6.4.2 only defines what happens when the authentication isn't >>> completed but not what happens when the authentication was completed. >>> >>> Maybe a<failure/> with<malformed-request/>. >> >> I'd say just ignore the new<auth/> element, since the entity is already >> authenticated. >> >>> Or should the server >>> proceed and throw away the authentication done before? >> >> No. There's no re-authentication option. >> >>> It's easy to fool clients into doing that, just announce<mechanisms/> >>> in<features/> when the stream got restarted after successfull >>> authentication. That itself isn't the correct thing to do, but >>> happens. ;) >> >> Why design around buggy servers? > > Hmm, I wouldn't say it's a bug in the server if he still announces > <mechanisms> in features when the stream got restarted after > authentication. > But I have to admit that RFC 3620 (and 6120, but not that verbose) > already said that the feature list is a kind of a state machine and not > a list of features of the server. I would prefer to see the feature list > as a list of features of the server and not the actual stream (or state > of), but the RFC don't. So I accept that it is a bug when announcing > <mechanisms> after the stream got negotiated. ;) In fact, a server *could* announce SASL mechanisms after authentication (if it allowed re-authentication of some unspecified kind). But in that case it shouldn't close the stream if the client tries to authenticate again. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
