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

From: Martin Rex <[email-masked]>
Date: Fri, 3 Nov 2006 21:25:38 +0100 (MET)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/spkm

---

From: Sam Hartman <[email-masked]>
Date: Sun, 05 Nov 2006 14:41:53 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:
    >> 
    >> 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.

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

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

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

I talked to Eric about this in another context.  He claimed that as a
practical matter it does not work if animplementation does a new
handshake without the cooperation of the upper-layer application.  You
are correct though that a DTLS GSS-API mechanism could only be
specified on the standards track if this issue were dealt with in some
manner that preserved the GSS-API model.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 5 Nov 2006 18:39:32 -0600

> manner that preserved the GSS-API model.

I would expect that a GSS-TLS mechanism wouldn't renegotiate anything
after initial security context establishment.  If there is a hard need
to (e.g., for re-keying), then expire the security context[*].

Alternatively, one of the things we've discussed is using TLS for
security context establishment, but the Kerberos V mechanism's
per-message tokens for per-message tokens, using the TLS PRF and master
secret to derive keys for them.  That would hand wave TLS re-negotiation
issues away as well, and would deal with re-key crypto needs no better
nor worse than the Kerberos V mechanisms.

IOW, this is not an issue (and if it is, then it's an issue for GSS-API
applications, and, maybe, for the GSS-APIv3 and v3 apps).

[*]  GSS apps have to be prepared to deal with this; the SASL GSS
     bridges, admittedly, don't.

Nico
--