chris.mullins at coversant.net
Thu Sep 28 20:47:53 UTC 2006
If we were to go down this route it seems as if a Time To Live (TTL)
feature could be added to the stream. This would allow servers to
examine SSL certs and issue an appropriate TTL, examine upcoming
password expiration dates and issue a TTL, or even have business rules
based on configuration settings.
One we get richer stream types (binary channels, etc) having a TTL like
this might be very nice. This would let me open a binary stream so some
resource, and have automatically closed after a preconfigured period of
time. Also, we could have stream-within-stream features that had defined
TTL's. We could also add in Karma type settings to this, so that after a
certain byte count, or a certain sustained bytes/per second value the
stream is terminated.
This could help also servers with the phantom connection issue that
always plagues those that don't use keep-alives.
From: standards-jig-bounces at jabber.org
[mailto:standards-jig-bounces at jabber.org] On Behalf Of Peter Saint-Andre
Sent: Thursday, September 28, 2006 1:34 PM
To: standards-jig at jabber.org
Subject: [Standards-JIG] re-authentication
Section 3.8 of RFC 4422 states:
Unless explicitly permitted in the protocol (as stated in the
protocol's technical specification), only one successful SASL
authentication exchange may occur in a protocol session.
Given that XMPP connections can be long-lived (you could be connected
for weeks or months!), it seems that we might want to define a way for
the server (i.e., receiving entity) to request re-authentication by the
initiating entity. (For example, perhaps the X.509 certificate you used
while authenticating expires during your session.)
On the other hand, I suppose the server could simply close the stream
with a <not-authorized/> error, but that's not very friendly.
Keeping things the way they are now has the advantage of being simple...
More information about the Standards