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
+ token, or when the GSSNegotiate RPC returns a zero-length output token
+ 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
+ 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
+ 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
+ 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
+ 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!
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
