[AFS3-std] rxgk/rxgk-afs updates

[Simon Wilkinson]

Comments below. I've swaped the order so we have oldest change first, as =
that seemed like the best order to think about it in.

> commit e8d2457b4e2f33cee6bc684008edfdd250eb6275
>    Attempt to make the GSS negotiation loop correct

+       The client detects a success condition when
+       gss_init_sec_context returns GSS_S_COMPLETE and a zero-length =
output=09
+       token, or when the GSSNegotiate RPC returns a zero-length output =
token=09
+       from the server.

Just having a zero length output token from the server isn't sufficient =
to declare success. gss_init_sec_context must have also returned =
GSS_S_COMPLETE in its last iteration.

+       A non-zero length output token always indicates that=09
+       another half-step is needed (gss_init_sec_context or =
GSSNegotiate),
+       as does a GSS major status including the flag =
GSS_S_CONTINUE_NEEDED.</t>

Except when the client has already returned a COMPLETE from =
gss_init_sec_context. In that situation, either a non-zero output token, =
or a CONTINUE_NEEDED status from the peer indicates an error.

>    Describing these things is always challenging.

Indeed. I've always felt that the SSH GSSAPI RFC made a pretty good bash =
of it, so perhaps there's language there that we can model ours on. Our =
GSS Negotiate loop is effectively what ssh-gss does in key exchange.

> commit db73249fa194cb05dccd2de9a8e97794592e9cc5
>    Talk about acceptor principal names for GSSNegotiate

I'm happy with the client side language, but...

+       The server's configuration as a GSS acceptor SHOULD NOT specify
+       a principal name for acceptor credentials, allowing the use of =
any
+       available credentials for the negotiation service.</t>

I strongly disagree here. The server should specify the identity which =
it is accepting. There have been numerous cross-service attacks in the =
past where flaws in service A can be used to compromise service B =
because they are both prepared to accept the same keys (not least, the =
original GSS ssh work). I would rather that we didn't end up being =
service A or service B - so I think the SHOULD NOT here is entirely =
inappropriate.

> commit a1f731943b2522a84c1815f2f056c3f3398ce9c6
>    Mention non-database non-files AFS servers

As far as I'm aware, previous discussion in this group and elsewhere was =
that bos isn't part of the AFS-3 protocol suite. My intention had always =
been that the rxgk-afs document would apply solely to RXAFS, RXAFSCB, PR =
and VL packages. Anything else would be covered either by the catch all =
rxgk document (where each service port provides a negotiation service), =
or by future standardisation. If this isn't sufficiently clear from the =
introduction to this document, then I think that that is the place to =
provide clarification.

+	 These per-service negotiation service
+        MAY reuse the acceptor credentials of the cell-wide key or they=09=

+        MAY use service-specific credentials.

The client needs clarity on the acceptor identity it is targeting - =
giving a choice means that the client needs to try multiple different =
negotiate calls in order to land upon the correct identity, which is =
both untidy, and untenable for some GSS mechanisms. Only the vlserver =
negotiation service may use the cell wide key as detailed in the =
rxgk-afs document. Per-service negotiation services must use an acceptor =
identity as detailed in the rxgk document (that is, one constructed =
using their IANA allocated service name). That's the only way you're =
going to be able to ensure interoperability.

> commit 34ed8c60f64b7c81cd0654b27cb8ee63b7621384
>    Allow empty authenticator appdata opaque for bosserver

This isn't necessary. You shouldn't be using rxgk-afs to talk to the =
bosserver. The application specific portion of the authenticator is as
specified by the core rxgk document (ie, empty)

> commit 620431272eb1365f3eb9fd3dcf89cd6c8195176c
>    Prescribe leap of faith for RegisterAddrsAndKey

+        VL_RegisterAddrs calls for that fileserver MUST only be =
accepted over an rxgk
+        protected connection secured using the same identity used to=09
+        secure the VL_RegisterAddrsAndKey RPC.

Non-departmental fileservers won't call VL_RegisterAddrsAndKey, instead =
they'll call VL_RegisterAddrs using a printed token. We need
language to indicate that this case is still permitted. How about =
replacing this paragraph with ...

  <t>Once a fileserver has been marked as supporting rxgk, =
VL_RegisterAddrs
  calls for that fileserver MUST only be accepted over an rxgk
  protected connection. vlservers MUST only accept calls to =
VL_RegisterAddrs
  from a printed token, an administrator, or the identity registered for =
the
  fileserver using a prior call to VL_RegisterAddrsandKey.</t>

+        The VL_RegisterAddrsAndKey RPC SHOULD NOT be allowed for =
existing=09
+        fileserver UUIDs that are not registered for rxgk, to prevent =
denial
+        of service attacks

How does a departmental fileserver register itself for rxgk? It doesn't =
have access to the cell-wide key, so can't print a token to
use RegisterAddrs. You also don't specify that once an identity has been =
registered for a departmental file server, only that identity may be =
used to call VL_RegisterAddrsAndKey.

How about the following revised language:

  <t>vlservers MUST NOT permit calls to VL_RegisterAddrsAndKey for UUIDs
     which already exist within the vldb, unless that vlserver already =
has
     a server-specific key registered. When a new fileserver first =
registers
     with the vldb using VL_RegisterAddrsAndKey, the vlserver MUST store =
the
     identity used to make this connection. The vlserver MUST only =
permit
     subsequent calls to VL_RegisterAddrsAndKey for this UUID when they =
come
     from this identity, an administrator, or a printed token.</t>

This still doesn't cover what to do if an administrator identity or =
printed token is used to call VL_RegisterAddrsAndKey first, as we don't =
want that identity being held within the vldb for all eternity!