On Tue, 5 Mar 2013, Simon Wilkinson wrote:
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.
Probably. I should have given a git log --reverse, sorry.
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.
I'll go revisit that RFC and respin this text.
(In my implementation I had been wavering between separately tracking the
initiator and acceptor major/minor status codes or just having a single
pair of variables. Doing this properly probably requires separate
tracking, it seems.)
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.
This text was based on a conversation with jhutz to the effect that
"servers should be liberal in what they accept", but I am not tightly
wedded to it. If the client needs application-specific knowledge to
choose a target principal name, then requiring that same
application-specific knowledge in the server hardly seems an overbearing
burden.
Do you want to just remove the text entirely, or change it to a SHOULD
specify the name, or something else?
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.
When I went to make this change, I actually first went to the introduction
to make a small clarification that it only covered database+fileservers.
However, I had a last minute change-of-heart because I wanted to use the
token format defined in this document for other services.
Of course, I can still use that token format without explicitly mentioning
those services in this document, so I should probably go back to my
original instinct.
+ 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.
Well, the rxgk document still allows a non-IANA-name service principal (it
is only a SHOULD), so a client may end up needing application-specific
knowledge regardless. I don't think we should preclude an implementor
from choosing to use the cell-wide key for all AFS-related services,
though perhaps we do not need to explicitly allow it.
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)
Given the previous comment, I'm happy to drop this.
I would not say that the core rxgk document specifys an empty app-specific
portion, though -- it is merely "application specific", and the
application must specify it to be empty if not needed.
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>
That works for me, modulo the second sentence not specifying rxgk
connections.
+ 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
s/vlserver/UUID/ ?
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>
We need to think about these two paragraphs together, as registering with
RegisterAddrsAndKey must force authentication for both future
RegisterAddrs and RegisterAddrsAndKey calls. I think that your proposed
texts do so, though. Thanks.
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!
I was thinking about just that problem yesterday! I haven't come up with
anything better than "manually frob the database", though. Maybe one
could kludge something by generating a new fileserver uuid, but that
hardly feels like a solution.
I'll make the indicated changes in the next day or two (destructively
rebasing as needed).
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
