RE: [TLS] the use cases for GSS-based TLS and the plea for integrating

[Chris Newman <[e-mail]>]

Larry Zhu wrote on 7/25/07 12:48 -0700:
> For use cases, please review my slides and the meeting minutes for the
> TLS working group. I would like to recap the main points below:

I will look at them.

> Methodology wise the way to deal with complexity is to build abstraction
> layers. GSS-API is ideal for encapsulating the described complexity.

Abstraction layers can decrease complexity, increase complexity, cause "data 
hiding" (good), and "data losing" (bad).  How abstraction layers are hooked 
together matters a great deal.  There's an abstraction layer between 
applications and TLS.  There's an abstraction layer between applications and 
SASL/GSSAPI.  But what you're proposing shoves GSSAPI behind the TLS 
abstraction, creating a clear case of "data losing" in the abstraction model. 
That would require punching holes through the TLS abstraction layer so the 
application can control both GSSAPI and any back channels GSSAPI uses to talk 
to user authentication repositories or trusted third parties.

> We strongly believe there is a confusing message in IETF. Our security
> AD made a presentation in the TLS working group yesterday and the
> message is that we want everyone to use TLS for everything.

A bit of a confused message is inevitable in a rough consensus organization. 
We're participating as individuals and have different perspectives and 
positions as individuals.  The work to form a rough consensus can be messy. 
But I hear your complaint and will talk to Tim to see if the two of us can 
agree on a more unified message.

For starters, I would agree that when a security services layer is needed in an 
application protocol stack that TLS is likely the right mechanism to provide 
that layer.  I'm not convinced the "SL" portion of "SASL" has any value in 
practice.

> No one wants to design their protocols
> once with Kerberos and once with TLS, no one want to review their
> protocols twice.  Experience has clearly shown that requiring two set of
> mechanisms (one for Kerb and one for TLS) adds a lot of unnecessary
> complexity to what is already too complex.

I'd agree that implementers only want to integrate one security services layer. 
But some implementers want their security services layer and identity stack to 
be as cleanly separated as possible so a tight binding between the two is not 
desirable.  TLS only provides certificate-based identity today, a mechanism 
that is very different from other user identity services because it does not 
require the TLS stack to perform a user identity network lookup in the middle 
of the TLS handshake.  Doing that means the TLS stack suddenly has to 
communicate problems talking to the identity lookup service through the TLS 
stack and back to the application.

> Not to mention the burden to
> test two sets of mechanisms. We the IETF really should build a better
> building block for future IETF standard protocols and deliver a coherent
> strategy/solution.

It's more important to build a strategy/solution that can be deployed and 
sustained in the real world with multiple independent interoperable 
implementations.

> Non-IETF protocols that do not have a SASL variant do not even have a
> choice, we have to integrate Kerberos into the TLS stack to get Kerberos
> to work, not to mention the practical reasons due to firewalls and NAT
> traversal.

An application protocol that needs user-level authentication and fails to 
include an authentication framing mechanism in the protocol is designed 
incorrectly, and the fact some non-IETF protocols have that problem is not a 
reason to add complexity to IETF protocols.  HTTP has such a framing mechanism, 
SSH has one, also SASL, GSSAPI and EAP include protocol abstractions that could 
be used to provide such a mechanism in any other application protocol.

If you try to solve the general application-layer user authentication problem 
in the TLS stack, that adds a bunch of requirements to TLS that it probably 
shouldn't have if there's a desire to keep the stack simple.  An example would 
be error messages suitable for end-user consumption and the language 
negotiation necessary for such messages (SSH does this, for example).

                - Chris


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls