Re: [jdev] service banners?

[Peter Saint-Andre]

Jefferson Ogata wrote:
> On 2006-07-19 15:49, Peter Saint-Andre wrote:
>> The question is not whether certain organizations need this, the
>> question is how to best do this in XMPP. IMHO we have two alternatives:
>>
>> 1. A new, optional attribute in the stream header. This informs the
>> receiving party of the service policy but does not require the receiving
>> party to affirm that they accept the service policy. Plus the client may
>>
>> 2. A new stream feature. This would involve a request-response model,
>>
>> The second option seems preferable to me, especially since it doesn't
>> require any changes to RFC 3920 (we can define stream features to our
>> heart's content, e.g. in a JEP). Naturally this is all XMPP 1.0 stuff,
>> older ("XMPP 0.9") clients might not be able to connect depending on how
>> much the service admins have locked things down. But I take it that is
>> the point.
> 
> Either would suit my particular purposes, I think. I see the logic of
> preferring option 2, although offhand I think it might require a bit
> more work to implement both on the client and the server side. In the
> lazy case, clients are free to ignore the message and simply send back
> the confirming reply automatically. The server has one more state to track.

Well, my understanding of your requirements is that you (may) need to
know if the end user has seen the banner and agreed to its terms before
allowing the user to authenticate. If so, (2) is the only way to go. If
your requirements are more lax, (1) might be acceptable (although I
really don't like anything that requires changes to RFC 3920).

In any case, working on this is not especially a high priority for me,
but if you'd like to collaborate, contact me off-list.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jdev] service banners?

[Jefferson Ogata]

On 2006-07-19 15:49, Peter Saint-Andre wrote:
> The question is not whether certain organizations need this, the
> question is how to best do this in XMPP. IMHO we have two alternatives:
> 
> 1. A new, optional attribute in the stream header. This informs the
> receiving party of the service policy but does not require the receiving
> party to affirm that they accept the service policy. Plus the client may
> 
> 2. A new stream feature. This would involve a request-response model,
> 
> The second option seems preferable to me, especially since it doesn't
> require any changes to RFC 3920 (we can define stream features to our
> heart's content, e.g. in a JEP). Naturally this is all XMPP 1.0 stuff,
> older ("XMPP 0.9") clients might not be able to connect depending on how
> much the service admins have locked things down. But I take it that is
> the point.

Either would suit my particular purposes, I think. I see the logic of
preferring option 2, although offhand I think it might require a bit
more work to implement both on the client and the server side. In the
lazy case, clients are free to ignore the message and simply send back
the confirming reply automatically. The server has one more state to track.

Thanks for giving it some thought.

-- 
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service

Re: [jdev] service banners?

[Jefferson Ogata]

On 2006-07-19 18:55, Hal Rottenberg wrote:
> Let me expand on the reasons for my first reply (which re-reading I
> see it looks a bit antagonistic which I didn't intend).

I dig.

> I don't see this as an oversight necessarily.  You are comparing
> apples and oranges when you bring SSH and such back into the
> discussion.  I looked--nowhere in the SSH RFC does it mention login
> banners.  I don't think it should be in the XMPP RFC either.

I don't see how it's apples and oranges. It is perfectly reasonable in
both cases to provide authorized usage information before a user gains
access to a system.

As for ssh:

>From RFC 4252:

5.4.  Banner Message

   In some jurisdictions, sending a warning message before
   authentication may be relevant for getting legal protection.  Many
   UNIX machines, for example, normally display text from /etc/issue,
   use TCP wrappers, or similar software to display a banner before
   issuing a login prompt.

   The SSH server may send an SSH_MSG_USERAUTH_BANNER message at any
   time after this authentication protocol starts and before
   authentication is successful.  This message contains text to be
   displayed to the client user before authentication is attempted.  The
   format is as follows:

  byte  SSH_MSG_USERAUTH_BANNER
  stringmessage in ISO-10646 UTF-8 encoding [RFC3629]
  stringlanguage tag [RFC3066]

   By default, the client SHOULD display the 'message' on the screen.
   However, since the 'message' is likely to be sent for every login
   attempt, and since some client software will need to open a separate
   window for this warning, the client software may allow the user to
   explicitly disable the display of banners from the server.  The
   'message' may consist of multiple lines, with line breaks indicated
   by CRLF pairs.

> Is what you are asking a valid concern and a good idea?  Yes, I agree
> there.  What I don't want to see is putting any new requirements on
> the clients if that can be avoided.  Putting it on servers is a better
> idea.  I'll leave the question of whether this is technically possible
> to the rest of you guys.

The requirements for the clients are pretty minimal, as far as I can
see. But let's see how the discussion goes...

-- 
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service

Re: [jdev] service banners?

[Dave Cridland]

On Wed Jul 19 19:55:06 2006, Hal Rottenberg wrote:
Is what you are asking a valid concern and a good idea?  Yes, I 
agree

there.  What I don't want to see is putting any new requirements on
the clients if that can be avoided.  Putting it on servers is a 
better
idea.  I'll leave the question of whether this is technically 
possible

to the rest of you guys.


Well, I strongly suspect that immediately after displaying a 
"banner", the client would continue authenticating, so I'm unsure of 
the actual value in working the protocol such that the text is sent 
prior to authentication. SSH, FTP, etc clients have this behaviour.


Basically, the client would continue the authentication 
automatically, where possible, and as I understand Jefferson's 
requirements, that would be taken to mean acceptance, which it quite 
obviously isn't.




Is an SASL anonymous connection sufficient for the client to be able
to receive an arbitrary XML stream?  Would a client be expcted to
display messages during this?  Can one login "trigger" another?  
Those

are the sorts of things going around in my head, but again, I'm not
pretending to know the answers on this part of the discussion.


SASL authentication is designed as a one-way gate - once 
authenticating, trying to authenticate again is an error. This isn't 
an XMPP thing, it's a SASL thing. In theory, the server might have 
dropped permissions needed to handle authentication by then.


There is, however, facility to send a message indicating that the 
terms and conditions have changed (or reminding the newly connected 
user where to find them, or even listing them), by sending a message 
stanza from the server. This works with all clients, and although 
it's post-authentication, the acceptance of these terms could be 
deduced from the first attempt to send a message.


Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [jdev] service banners?

[Hal Rottenberg]

On 7/19/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:

Look at how FTP, ssh2, or rsync do it. Really, it is an oversight that
this is not currently built in to XMPP; it's trivial to define an
attribute or element at the beginning of the stream element to handle
this. It's a matter of specifying that and then having clients present
it to the user before logging in. The original question was simply
whether this was in the protocol definition anywhere, and I think Peter
answered quite clearly right off the top.


Let me expand on the reasons for my first reply (which re-reading I
see it looks a bit antagonistic which I didn't intend).

I don't see this as an oversight necessarily.  You are comparing
apples and oranges when you bring SSH and such back into the
discussion.  I looked--nowhere in the SSH RFC does it mention login
banners.  I don't think it should be in the XMPP RFC either.

Is what you are asking a valid concern and a good idea?  Yes, I agree
there.  What I don't want to see is putting any new requirements on
the clients if that can be avoided.  Putting it on servers is a better
idea.  I'll leave the question of whether this is technically possible
to the rest of you guys.

Is an SASL anonymous connection sufficient for the client to be able
to receive an arbitrary XML stream?  Would a client be expcted to
display messages during this?  Can one login "trigger" another?  Those
are the sorts of things going around in my head, but again, I'm not
pretending to know the answers on this part of the discussion.

--
Psi webmaster (http://psi-im.org)
im:[EMAIL PROTECTED]
http://halr9000.com

Re: [jdev] service banners?

[Peter Saint-Andre]

Jefferson Ogata wrote:

> Again, the requirement is that this occur before authentication.
> 
> Look at how FTP, ssh2, or rsync do it. Really, it is an oversight that
> this is not currently built in to XMPP; it's trivial to define an
> attribute or element at the beginning of the stream element to handle
> this. It's a matter of specifying that and then having clients present
> it to the user before logging in. The original question was simply
> whether this was in the protocol definition anywhere, and I think Peter
> answered quite clearly right off the top.

The question is not whether certain organizations need this, the
question is how to best do this in XMPP. IMHO we have two alternatives:

1. A new, optional attribute in the stream header. This informs the
receiving party of the service policy but does not require the receiving
party to affirm that they accept the service policy. Plus the client may
not understand the new attribute and thus ignore it. Therefore the
server would never know if the policy has been shown to a user, let
alone whether the user agrees to abide by the policy.

2. A new stream feature. This would involve a request-response model,
wherein the server sends the current policy to the client and the client
MUST show the policy to the human user (if any) and the client MUST
return some kind of ack to the server (yes, I showed it to the human and
the human agreed to abide by the policy). The server could make receipt
of the ACK necessary in order to proceed (a la  for TLS) and
provide only the service banner in the initial stream feature set. Thus
the server could know that a user has seen and agrees to the policy
before allowing the client to proceed with TLS and SASL.

The second option seems preferable to me, especially since it doesn't
require any changes to RFC 3920 (we can define stream features to our
heart's content, e.g. in a JEP). Naturally this is all XMPP 1.0 stuff,
older ("XMPP 0.9") clients might not be able to connect depending on how
much the service admins have locked things down. But I take it that is
the point.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jdev] service banners?

[Jefferson Ogata]

On 2006-07-19 12:32, Tobias Markmann wrote:
> You can put that kind of information, disclaimer, TOS, etc., in the
> registration form which your server returns to the client which is going
> to create a account. If that isn't supported the server can just provide
> Off-Band Registration where the user can read all that info before applying.
> http://www.jabber.org/jeps/jep-0077.html
> 

That is not sufficient. First of all, users need to be notified every
time they access the service, as a reminder, and because terms of
service may change over time. Second, users will never register, as they
will simply be authenticating against an existing authentication service.

> For users who already have an account most server admins just send a
> message to all users on changes on that topic.

Again, the requirement is that this occur before authentication.

Look at how FTP, ssh2, or rsync do it. Really, it is an oversight that
this is not currently built in to XMPP; it's trivial to define an
attribute or element at the beginning of the stream element to handle
this. It's a matter of specifying that and then having clients present
it to the user before logging in. The original question was simply
whether this was in the protocol definition anywhere, and I think Peter
answered quite clearly right off the top.

-- 
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service

Re: [jdev] service banners?

[Tobias Markmann]

You can put that kind of information, disclaimer, TOS, etc., in the registration form which your server returns to the client which is going to create a account. If that isn't supported the server can just provide 
Off-Band Registration  where the user can read all that info before applying.http://www.jabber.org/jeps/jep-0077.html
For users who already have an account most server admins just send a message to all users on changes on that topic. On 7/19/06, Trejkaz <
[EMAIL PROTECTED]> wrote:On Wednesday 19 July 2006 18:46, Benjamin Podszun wrote:
> Please - don't mix banners with braindead and completely useless eMail> signatures.. These disclaimers you are probably talking about are> largely deemed irrelevant and I've yet to find one that really contains
> anything worth the bandwidth.Whereas in contrast, IRC server MOTDs are things anyone who uses the servicewould be able to recite off the top of their heads, having read them socarefully.TX
-- Email: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED]  Web site: 
http://trypticon.org/   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73

Re: [jdev] service banners?

[Trejkaz]

On Wednesday 19 July 2006 18:46, Benjamin Podszun wrote:
> Please - don't mix banners with braindead and completely useless eMail
> signatures.. These disclaimers you are probably talking about are
> largely deemed irrelevant and I've yet to find one that really contains
> anything worth the bandwidth.

Whereas in contrast, IRC server MOTDs are things anyone who uses the service 
would be able to recite off the top of their heads, having read them so 
carefully.

TX

-- 
 Email: [EMAIL PROTECTED]
 Jabber ID: [EMAIL PROTECTED]
  Web site: http://trypticon.org/
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73


pgpAigcF1B3T1.pgp
Description: PGP signature

Re: [jdev] service banners?

[Benjamin Podszun]

[EMAIL PROTECTED] wrote:
> I see the need for your feature requests.
> 
> I presume if users go through any provisioning steps to register an
> account with your service than that would be one place for such a
> disclaimer.

> If you permit in-band account registration, the welcome message could be
> another place.

He specifically said that this is not what he wants. He expects a banner
that you read _before_ you use the service. Yes, even before you
register/authorize.

> If you need to remind the user on each subsequent login, then perhaps an
> attribute to the stream opening exchanges might contain a URL to the
> policy of the server ?
> 
> Will you be federating your server  ?
> 
> Should the generic requirement for a banner/disclaimer like service also
> apply to a user who is federating to a remote server ?

Interesting point. I think of this banner as a local service
description, but it might make sense to notify user X at company1 that
the company2 server he just starts to send messages to logs everything etc.

>  In the email domain this has usually been done with signatures in each
> message ( the end users will never see the SMTP S2S connection) - and in
> case of AOL etc across company boundaries the remote company if they are
> logging my messages sends a disclaimer (in-band) at the start of each
> session with one of their employees.

Please - don't mix banners with braindead and completely useless eMail
signatures.. These disclaimers you are probably talking about are
largely deemed irrelevant and I've yet to find one that really contains
anything worth the bandwidth.

Ben

Re: [jdev] service banners?

[ennova2005-jabber]

I see the need for your feature requests.I presume if users go through any provisioning steps to register an account with your service than that would be one place for such a disclaimer. If you permit in-band account registration, the welcome message could be another place.If you need to remind the user on each subsequent login, then perhaps an attribute to the stream opening exchanges might contain a URL to the policy of the server ? Will you be federating your server  ? Should the generic requirement for a banner/disclaimer like service also apply to a user who is federating to a remote server ?  In the email domain this has usually been done with signatures in each message ( the end users will never see the SMTP S2S connection) - and in case of AOL etc across company boundaries the remote company if they are logging my messages sends a disclaimer (in-band) at the start of each session with one of their
 employees.Jefferson Ogata <[EMAIL PROTECTED]> wrote:<[EMAIL PROTECTED]>Accessing an XMPP service /is/ a remote server login.Bannering is a pretty commonplace feature of modern network services.

Re: [jdev] service banners?

[Jefferson Ogata]

On 2006-07-19 02:00, Hal Rottenberg wrote:
> On 7/18/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
>> Is there any provision in XMPP or JEPs for service banners? By this I
>> mean proper banners such as are supported by ssh2, as well as
>> traditional protocols such as FTP and telnet. A requirement is that the
>> banner be presented to the user before authentication. An MOTD doesn't
>> qualify here.
> 
> May I ask why?  I totally understand the concept of having a login
> banner such as the one that I install on my own Windows domains at
> work.  Disclaimers and such.
> 
> Do you present a banner to users at login to a system?  Yes.
> 
> But do you then present a banner to the user at each subsequent
> application they execute?  Do you show a banner when the user opens
> their mail?  I think this is taking the concept a bit too far here.

I don't know where you're going with this. XMPP is a remotely accessible
service. I need to reliably advise potential users about service
policies (including monitoring and applicable law) before they use the
system. I don't have control over what banners remote users see when
they log in to their local domains (presuming that they're even using
Windows), so I don't see how that is in the least relevant.

> Usually you'll see these banners at the point of entry as it were.  On
> your local workstation or a remote server login.  But once you are in
> it seems a bit superfluous.

Accessing an XMPP service /is/ a remote server login.

Bannering is a pretty commonplace feature of modern network services.

> Let me know if I'm off track...

Sorry, but you're off track.

-- 
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service

Re: [jdev] service banners?

[Matthew A. Miller]

Hal Rottenberg wrote:

On 7/18/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:

Is there any provision in XMPP or JEPs for service banners? By this I
mean proper banners such as are supported by ssh2, as well as
traditional protocols such as FTP and telnet. A requirement is that the
banner be presented to the user before authentication. An MOTD doesn't
qualify here.


May I ask why?  I totally understand the concept of having a login
banner such as the one that I install on my own Windows domains at
work.  Disclaimers and such.

Do you present a banner to users at login to a system?  Yes.

But do you then present a banner to the user at each subsequent
application they execute?  Do you show a banner when the user opens
their mail?  I think this is taking the concept a bit too far here.

Usually you'll see these banners at the point of entry as it were.  On
your local workstation or a remote server login.  But once you are in
it seems a bit superfluous.

Let me know if I'm off track...



This sounds about right to me, too.



--
-  LW

"Got JABBER(R)?" 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jdev] service banners?

[Hal Rottenberg]

On 7/18/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:

Is there any provision in XMPP or JEPs for service banners? By this I
mean proper banners such as are supported by ssh2, as well as
traditional protocols such as FTP and telnet. A requirement is that the
banner be presented to the user before authentication. An MOTD doesn't
qualify here.


May I ask why?  I totally understand the concept of having a login
banner such as the one that I install on my own Windows domains at
work.  Disclaimers and such.

Do you present a banner to users at login to a system?  Yes.

But do you then present a banner to the user at each subsequent
application they execute?  Do you show a banner when the user opens
their mail?  I think this is taking the concept a bit too far here.

Usually you'll see these banners at the point of entry as it were.  On
your local workstation or a remote server login.  But once you are in
it seems a bit superfluous.

Let me know if I'm off track...

--
Psi webmaster (http://psi-im.org)
im:[EMAIL PROTECTED]
http://halr9000.com

Re: [jdev] service banners?

[Peter Saint-Andre]

Jefferson Ogata wrote:
> Is there any provision in XMPP or JEPs for service banners? By this I
> mean proper banners such as are supported by ssh2, as well as
> traditional protocols such as FTP and telnet. A requirement is that the
> banner be presented to the user before authentication. An MOTD doesn't
> qualify here.

Hmm, no. In XMPP we'd probably have to return the service banner in the
XML stream header but we don't have a way to do that right now. I'll
have to think about it a bit to see how we might design that.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

[jdev] service banners?

[Jefferson Ogata]

Is there any provision in XMPP or JEPs for service banners? By this I
mean proper banners such as are supported by ssh2, as well as
traditional protocols such as FTP and telnet. A requirement is that the
banner be presented to the user before authentication. An MOTD doesn't
qualify here.

-- 
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service