[AFS3-std] rxgk/rxgk-afs updates

[Benjamin Kaduk]

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