Subject: My concerns about a SRP SASL mechanism

From: [email-masked] (Sam Hartman)
Date: Fri, 4 Apr 2003 16:08:46 -0500 (EST)

I've been asked to clarify my objections to an SRP SASL mechanism.

The basic objection is that mechanism designers should write GSSAPI
mechanisms not SASL mechanisms unless they have a good reason to do
otherwise.

If the SRP mechanism was a GSSAPI mechanism then it could be used
   unmodified within SSH, NFS V4 and other protocols that support
   GSSAPI for security within the IETF and within other areas.  It
   could also be used with all the protocols that use SASL.  

If SRP is useful, then people will want to use it with other protocols
and so we should try to make sure it is useful with all those
protocols.  The IETF is busy and reviewing security documents takes
time.  So we should find the solution that involves minimizing review
within the IETF while maximizing the number of situations where the
technology is useful.  

Here are some objections I can see to writing the SRP SASL mechanism
in the form of a GSSAPI mechanism:

1)  We're almost done with the existing draft.

    Up until now the document has not received significant review
    within the IETF.  It has not been a work product of a working
    group  and has not been last called before.  When a document is
    submitted to the IETF for the standards track, the IETF receives
    change control and needs the opportunity to  make (potentially
    significant) changes to the document.

2)  GSSAPI  libraries are hard to deal with and multi-mechanism GSSAPI
    support is weak

    There is no requirement that you use a GSSAPI library or even  the
    GSSAPI within your program to implement a SASL GSSAPI mechanism.
    You simply need to  have a compatible wire encoding, but you can
    actually implement the mechanism the same as you would implement
    other SASL mechanisms if you find that an easier implementation
    choice.

Here's roughly what would need to happen to turn a SASL mechanism into
a standards track GSSAPI mechanism

1) You need to use the GSSAPI initial context token format.  this
   means you need to include an OID and a bit of header at the
   beginning of the authentication messages.

2)  You need to assign an OID to your mechanism.

3) You may need to think about name formats for principal names a bit.

4) There may be some issues involving out-of-order delivery of
   messages you need to think about.

5) You should organize the document so it will be clear both to people
   implementing as a SASL mechanism and as a GSSAPI mechanism.

---

From: Keith Burdis <[email-masked]>
Date: Sat, 5 Apr 2003 01:17:02 +0000

> mechanisms not SASL mechanisms unless they have a good reason to do

I have no problem with the GSS-API, but it is far from simple. Compare the 85 
pages in RFC 2078 with the 16 pages in RFC 2222. 

The basic question is: why should mechanism designers bother with the 
complexity of GSS-API when they can design much simpler SASL mechanisms? The 
reason that SASL came about was because alternatives like the GSS-API were 
too complicated.

I agree that an SRP GSS-API mechanism [1] would be great to have, but that is 
no reason not to have an SRP SASL mechanism. In our opinion trying to merge 
the two is not a good idea.

>    could also be used with all the protocols that use SASL.

Quite true.

> within the IETF while maximizing the number of situations where the

It sounds to me like you are saying that we should not have any other SASL 
mechanisms other than the SASL GSS-API mechanism. If so, then what is the 
point of SASL? Is it then just a wrapper for GSS-API?

>     significant) changes to the document.

It is not the product of a working group because someone decided that it 
wasn't appropriate due to problems with US patents. It has however been 
discussed on this mailing list on and off for four years. We have no problem 
with making any changes to the document as long as we feel they are 
justified. The current document is very different to the orginal version and 
has benefited significantly from feedback received.

>     other SASL mechanisms if you find that an easier implementation

It is not really the same as other SASL mechanisms, because there is extra 
"baggage" included.

>    beginning of the authentication messages.

It also means we have to deal with ASN.1:

   InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
        thisMech OBJECT IDENTIFIER,
        innerContextToken ANY DEFINED BY thisMech
      }

This is meaningful for GSS-API, but from an SASL mechanism perspective, this 
means that we have a bunch of garbage bytes at the beginning of our exchange.

> 2)  You need to assign an OID to your mechanism.

Ok.

> 3) You may need to think about name formats for principal names a bit.

We don't put any restrictions on name formats, only encodings.

>    messages you need to think about.

In the authentication exchange or in the security layer?

>    implementing as a SASL mechanism and as a GSSAPI mechanism.

The whole point of SASL is that it is simple. Each of the points above adds 
complexity to the mechanism. I am not completely dismissing the idea, but I 
am not convinced that this complexity is justified in the context of what 
SASL is trying to achieve - simple authentication.

  - Keith

[1] http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt

---

From: Sam Hartman <[email-masked]>
Date: Sat, 05 Apr 2003 09:55:56 -0500

[I tried to make this clear at the working group meeting, but it
didn't really make it into the minutes.  The SRP mechanism is out of
scope for this working group, so I am not acting as chair in this
discussion.  I am acting as an interested party.  Should this
specification ever become a work item of this working group, I'll find
someone else to argue this position so I can be an effective chair.]

,
>>>>> "Keith" == Keith Burdis <[email-masked]> writes:

    Keith> On Friday 04 Apr 2003 21:08, Sam Hartman wrote:
    >> The basic objection is that mechanism designers should write
    >> GSSAPI mechanisms not SASL mechanisms unless they have a good
    >> reason to do otherwise.

    Keith> I have no problem with the GSS-API, but it is far from
    Keith> simple. Compare the 85 pages in RFC 2078 with the 16 pages
    Keith> in RFC 2222.

I think comparing the page counts is a significantly misleading
complexity metric.  I believe that the complexity of a simple GSSAPI
mechanism is not significantly more than the complexity of a simple
SASL mechanism with a security layer.  There are certainly GSSAPI
mechanisms that are more complex than non-GSSAPI SASL mechanisms, but
this is not required.

    Keith> The basic question is: why should mechanism designers
    Keith> bother with the complexity of GSS-API when they can design
    Keith> much simpler SASL mechanisms? 

First, I  don't think there is that much more complexity involved.

But my primary concern is that review and specification of a
technology for multiple protocols is much more expensive than taking
the work up front to specify the technology for a framework.
Specifying SRP for all the other protocols that use GSSAPI would take
more time than doing a SRP GSSAPI mechanism rather than a SASL
mechanism.  Even if we could reuse significant ideas from the SASL
mechanism, doing the work to compare and contrast the results of all
the SRP specifications against each other making sure that they worked
well together and that there were not bugs introduced as ideas were
copied would be significantly greater than the cost of specifying a
GSSAPI mechanism now.

The only way specifying a SASL mechanism makes sense is if we hope
never to have to do the work of specifying a GSSAPI mechanism later or
to specify SRP for other protocols that support both GSSAPI and other
authentication technology.  There are two reasons this might be the
case.  The first is that SRP might not get enough deployment to matter
for those protocols.  The second is that SRP is somehow uniquely
suited to applications that use SASL but not to current and future
protocols that use GSS.

If SRP is not going to get enough deployment for future work, then we
shouldn't even bother with the SASL mechanism.  Specification review
effort is very expensive and we're all fairly busy as is.

I can't think of a reason why SRP would be more suited to email,
directory access, etc than say file sharing or remote login.  If you
can then I'll certainly reconsider.

    Keith> The reason that SASL came
    Keith> about was because alternatives like the GSS-API were too
    Keith> complicated.

I think the complexity being complained about was mostly on the
application side--GSSAPI is hard to integrate into a protocol.  I
don't think the same complexities really exist on the  mechanism side.

SASL was also important because there exist SASL mechanisms that do
not have enough features to be GSS mechanisms.

    Keith> I agree that an SRP GSS-API mechanism [1] would be great to
    Keith> have, but that is no reason not to have an SRP SASL
    Keith> mechanism. 

I think it is.  First, I think the costs of doing both an SRP GSS
mechanism and an SRP SASL mechanism are significantly higher than the
costs of the GSS mechanism alone.  Second, having multiple ways to use
SRP in the same protocol will confuse site administrators and users
and make configuration more complex.

    >> If SRP is useful, then people will want to use it with other
    >> protocols and so we should try to make sure it is useful with
    >> all those protocols.  The IETF is busy and reviewing security
    >> documents takes time.  So we should find the solution that
    >> involves minimizing review within the IETF while maximizing the
    >> number of situations where the technology is useful.

    Keith> It sounds to me like you are saying that we should not have
    Keith> any other SASL mechanisms other than the SASL GSS-API
    Keith> mechanism. If so, then what is the point of SASL? Is it
    Keith> then just a wrapper for GSS-API?

I think the point of SASL is to be a convenient way to add
authentication to applications.  It happens to encapsulate a lot of
the GSS complexity that will be the same for all applications.  It
also provides for mechanisms that are too weak to be GSS mechanisms.

Applications should use SASL if they can live within its constraints.
Except in some special cases mechanisms should be designed for GSS.
    >> 2) GSSAPI libraries are hard to deal with and multi-mechanism
    >> GSSAPI support is weak
    >> 
    >> There is no requirement that you use a GSSAPI library or even
    >> the GSSAPI within your program to implement a SASL GSSAPI
    >> mechanism.  You simply need to have a compatible wire encoding,
    >> but you can actually implement the mechanism the same as you
    >> would implement other SASL mechanisms if you find that an
    >> easier implementation choice.

    Keith> It is not really the same as other SASL mechanisms, because
    Keith> there is extra "baggage" included.

A few extra bytes at the beginning of the context tokens doesn't seem
unacceptable.

    >> Here's roughly what would need to happen to turn a SASL
    >> mechanism into a standards track GSSAPI mechanism
    >> 
    >> 1) You need to use the GSSAPI initial context token format.
    >> this means you need to include an OID and a bit of header at
    >> the beginning of the authentication messages.

    Keith> It also means we have to deal with ASN.1:

False.  The GSSAPI spec defines the context token header both in terms
of ASN.1 and in terms of raw bytes.  It explicitly states that the raw
bytes definition is authoritative.

You could choose to use ASN.1 if you like, or you could just emit the
context token header for your mechanism, listing it as raw bytes in
your specification.

    >> messages you need to think about.

    Keith> In the authentication exchange or in the security layer?

security layer.

    Keith> [1]
    Keith> http://www.spheniscidae.co.uk/~keith/ietf/draft-ietf-cat-srpgm-01.txt

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Apr 2003 14:47:31 -0700

>    implementing as a SASL mechanism and as a GSSAPI mechanism.

Sam, do you volunteer to write a paragraph that describes a binary
representation for the GSSAPI header?
If you (or somebody else) do this, we would be done with this discussion.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: Keith Burdis <[email-masked]>
Date: Sat, 5 Apr 2003 01:17:02 +0000

Quite true.

Ok.

  - Keith

---

From: Sam Hartman <[email-masked]>
Date: Sat, 05 Apr 2003 09:55:56 -0500

,

security layer.

    Keith> [1]

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Apr 2003 14:47:31 -0700

Cheers,
Alexey