On Mon, Apr 1, 2013 at 12:01 PM, Benjamin Kaduk <kaduk@xxxxxxx> wrote:
> Section 3.2.1.1 of this document ("Kerberos V5 as a security triple") seems
> to indicate that it is mandatory for a conformant NFSv4 implementation to
> implement the Kerberos V5 GSS-API mechanism and a few "security triples"
> (mechanism,quality of protection,service). All of the
> mandatory-to-implement security triples use the DES-MAC-MD5 algorithm. The
> draft goes on to indicate that clients should engage in security negotiation
> (section 3.3) to determine what security to use for bulk operation, and that
> since kerberos-v5 under RPCSEC_GSS is mandatory, the negotiation will be
> performed using that security provider. The actual mechanism resulting from
> the negotiation may be different (or may be the same), but this single-DES
> mechanism seems to be required to be used to protect the negotiation step.
Oh, well, this is just outdated text. And indeed, the GSS-API's
notion of "qop" (quality of protection) is broken: it's used in the
wrong place (per-msg token functions). The GSS qop brokenness is why
this text persists.
OLD:
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == mechanism's algorithm(s)
5 == RPCSEC_GSS service
1 2 3 4 5
--------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy
for integrity,
and 56 bit DES
for privacy.
NEW:
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == qop
5 == RPCSEC_GSS service
1 2 3 4 5
--------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy
KITTEN WG should undertake an extension to replace the broken qop concept.
Nico
--