[SPKM] Re: [TLS] DTLS and GSS-API

Sam Hartman wrote:
> 
> Monday morning at IETF 67 there is a really important BOF: SPKM.
> 
> The purpose of this BOF is to decide how we will get a standards track
> solution for NFSV4 to use PKI credentials.  Two modes are important: a
> mode where both parties have credentials and a mode where the server
> has a certificate and the client has a password.
> 
> The current proposal is based off draft-adamson-rfc2847-01.txt.
> Several reviewers including Eric Rescorla and myself have expressed
> concerns about this draft.

I noticed Erics comments about the crypto algorithms, how they're
enumerated and combined.  Without checking the details, I believe
this stuff is more-or-less a straight copy from the original SPKM spec
(rfc-2025), not a conscious selection of the current document author,
and a result of trying to remain backwards compatible as much as
possible, and not because it is any useful.

> 
> 
> An alternate proposal for solving this problem was discussed in the
> past: construct a GSS-API mechanism based on DTLS.  Advantages of this
> solution include reuse of code and specification between GSS-API and
> TLS implementations.  When new ciphers are specified for TLS they
> would be available for NFS.  We would not need to keep updating a GSS
> mechanism as public-key algorithms evolve and problems are found.
> 
> There are two main drawbacks I've heard to the DTLS proposal.  First,
> we don't have a draft.  Second, it would not be interoperable with
> SPKM-3 deployments.

There is a substantial difference between GSS-API and TLS which
should not be ignored:  In the GSS-API architecture, context
level tokens (which exchange cryptographic material and perform
the authentication) can only be exchanged at the beginning.

After a security context has been established, the message flow
depends entirely on the communication characteristics of the
application, and may be entirey uni-directional and may preclude
even alien attempts of a gssapi mechanism to piggy-back context-token
on protected message tokens.

With TLS, on the other hand, each of the communication peers may
request a renegotiation of context parameters at (almost) any time
during the communication.

A GSS-API mechanism built on TLS should not attempt to piggy-back
any additional information on protected message tokens (and make
assumptions about the communcation characteritics of the application
caller).  Some applications will break when the message protection
token size (get_mic) or the message size increase (wrap) increases
considerably in order to accomodate piggy-backed context-update.
Some GSS-API applications may not be able to cope with it --
the message protection overhead is expected to be fairly low
in GSS-API, and applications have been encouraged to squeeze
tighltly with the introduction of "gss_wrap_size_limit()"
in GSS-API v2. 

-Martin

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm