[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
      string    message in ISO-10646 UTF-8 encoding [RFC3629]
      string    language 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 <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service