[TLS] Re: Comments on draft-housley-tls-authz-extns-07

[Simon Josefsson <simon at josefsson.org>]

pgut001 at cs.auckland.ac.nz (Peter Gutmann) writes:

> Pasi.Eronen at nokia.com writes:
>
>>I think this document is somewhat useful; and given that there are others who
>>seem to share this view -- and basically nobody has claimed that the
>>technical solution is flawed or undesirable -- I think IESG should publish
>>this document. IMHO not publishing this as a form of punishment would be a
>>wrong thing to do.
>
> One potential problem with it is that we're seeing a pile of alternative-
> authentication-method proposals for TLS, and there may be better (more
> flexible or compatible-with-existing) ways of doing this.  In addition since
> there does seem to be a fair bit of interest in this, having a universal
> framework to handle it and then allowing individual mechanisms as profiles
> within the framework may be a better approach.
>
> At the moment we have two ways to do TLS-alternative-auth, either make it part
> of the TLS handshake (that is, modify the crypto portion of the TLS
> handshake), or add it as a TLS extension protocol.  The former approach is
> used by TLS-KRB5, TLS-PSK, and TLS-SRP.  The latter approach is used by (at
> least) TLS-Authz and TLS-EAP (and I think I may have seen one or two probably
> now-expired drafts float past in the past as well).
>
> If this is a useful way to handle it, then it looks like the question is
> "Which of TLS-Authz, TLS-EAP, (or potential other approaches) provides the
> better framework for defining extensible authentication services within TLS?".

Hold on!  Tls-authz isn't about authentication.  It is about
authorization.

Authorization is (or at least could be) orthogonal to authentication.  I
haven't seen many competing proposals to solve authorization in TLS,
although the technology is simple if you know about TLS and the
authorization concept.

Btw, one approach to support TLS-alternative-auth is to write profiles
of TLS-PSK for each alternative authentication mechanism.  The mechanism
has to be able to generate cryptographic keys, but I believe good
authentication mechanisms (should) have this property.  Then no changes
to TLS would be required.

/Simon

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls