[AFS3-std] Re: Revised PTS authentication name mapping draft, call for review

[Derrick Brashear]

I have again revised this draft based on feedback, and -03 is available.

https://datatracker.ietf.org/doc/draft-brashear-afs3-pts-extended-names/

I declined to abridge the explanatory text regarding AFS history at
this time, as there is no suitable work to refer to at this time.

Aside from that, I know of one outstanding issue, which in addition to
any comment I would like to explicitly seek feedback on.

One commenter (who I will allow to out themselves if they wish) says:
"I'm still uneasy about requiring the rewriting of GSSAPI-obtained
Kerberos names to use the Kerberos name type. If we believe that
GSSAPI is the future, then I would prefer that we use the GSSAPI
exported name for all GSSAPI mechanisms, rather than special casing
Kerberos.

If I am building a hypothetical AFS product which only supports
GSSAPI, I'm not sure why I should be forced to have my server convert
from GSSAPI to Kerberos v5 names, when I actually have no interest at
all in the Kerberos v5 name.

I think a better approach would be to require ptservers in cells which
support multiple implementations of the same underlying security
mechanism to perform the mapping. So, if you have a cell which
supports both native Kerberos v5, and GSSAPI, then the ptserver should
be responsible for mapping from the GSSAPI name to the Kerberos v5
one, and vice versa."

As long as we have chosen a single consistent mechanism for
representing Kerberos 5 names there should not be an issue, and this
proposal does so; As such I would be willing to incorporate it if
consensus is behind it.


-- 
Derrick