Subject: SCRAM and mechanism family

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Nov 2008 13:03:06 +0100

I brought this up on the jabber chat during the WG presentation of
SCRAM, but it may be useful to repeat here to get feedback.

Why does SCRAM needs to be defined as a mechanism family?

If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
obvious reason for defining SCRAM as a family, taking the current SCRAM
document and replacing SHA-1 with SHA-256 is possible.

The non-family approach has the benefit of making it simple to introduce
improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
necessary.

I think SASL mechanism families introduce complexity for little gain,
but I'd be interested to understand why it was added here.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Nov 2008 08:00:22 -0600

>Why does SCRAM needs to be defined as a mechanism family?
It doesn't have to. But the document already defines any SCRAM mechanism 
as if the hash function is pluggable. I personally like it like that and 
I don't see a reason to change the document.

>improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
While this is true, I would hate to have a set of similar, but slightly 
different mechanisms.
If this happens, I would be strongly in favour of changing the mechanism 
prefix name.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 20 Nov 2008 16:14:58 +0100

One one hand, having a single name saves clutter. I know I can use the 
same code for all SCRAM varieties if they're defined using the same 
words in the same document.

On another, how many varieties are expected in the foreseeable future? 
1? 2? A generic mechanism that covers one or two cases has bad karma, 
and one that is meant to cover the unforeseeable future in cryptography 
and computer security has really awful karma.

So I think that overall maybe I agree with Simon.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Nov 2008 09:36:12 -0600

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>It doesn't have to. But the document already defines any SCRAM
>>mechanism as if the hash function is pluggable. I personally like it
>>like that and I don't see a reason to change the document.
>>    
>>
>>While this is true, I would hate to have a set of similar, but
>>slightly different mechanisms.
>>If this happens, I would be strongly in favour of changing the
>>mechanism prefix name.
>>    
>>
>For a non-family mechanism, there is no prefix, so changing the name
>from SCRAM-HMAC-SHA-1 to SCRAM-HMAC-SHA-256 will change the name and
>make them non-equivalent from a SASL library perspective.
>  
>
I was thinking more from a developer prospective: trying to remember 
subtile differences between similar things is hard.

>But I don't care strongly, I was trying to understand if there were a
>strong reason to do this rather than a preference.
>  
>
No strong reason.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Nov 2008 16:19:47 +0100

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Nov 2008 11:05:17 -0600

Arnt Gulbrandsen wrote:

> and one that is meant to cover the unforeseeable future in 
> cryptography and computer security has really awful karma.
>

I wanted to write a small rant in reply ;-), but I've realized there 
might be a couple of related issues here:

1). Structure of the document - SCRAM currently written with an 
assumption that any hash function can be used with it
2). Definition of SCRAM-HMAC-SHA-1 and IANA registration.

I am quite reluctant to change 1). Speaking personally I have plenty of 
of other things to do that I consider more important and I am not 
looking forward potentially creating more work for myself by hardcoding 
the hash name in various places of the document.

Speaking of 2): we've actually discussed this during the WG meeting in 
Minneapolis and the room consensus was to NOT register a family of 
SCRAM-HMAC mechanisms, but only register SCRAM-HMAC-SHA-1 and add some 
text that any further SCRAM-HMAC-* registrations would need to be done 
on the case by case basis. I will update the document to match, unless 
somebody has a strong objection.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Nov 2008 11:20:32 -0600

Alexey Melnikov wrote:

> I am quite reluctant to change 1). Speaking personally I have plenty 
> of of other things to do that I consider more important and I am not 
> looking forward potentially creating more work for myself by 
> hardcoding the hash name in various places of the document.
>

I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1 with 
IANA.
I've also added the following text:

Note that even though this document defines a family of SCRAM-HMAC 
mechanisms,
it doesn't register a family of SCRAM-HMAC mechanisms in the SASL Mechanisms
registry. IANA is requested to prevent future registrations of SASL 
mechanisms
starting with SCRAM-HMAC- without consulting the SASL mailing list
<[email-masked]> first.

Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC SASL
mechanism MUST be explicitly registered with IANA and MUST comply with
SCRAM-HMAC mechanism naming convention defined in Section 4 of this 
document.

Comments?
(Is the text entirely consistent? I am wondering if instructing IANA not 
to register future SCRAM-HMAC mechanism without consulting the mailing 
list is in fact a registration of the new SCRAM-HMAC family of SASL 
mechanisms?)

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Nov 2008 22:24:56 +0100

Alexey Melnikov <[email-masked]> writes:

> Arnt Gulbrandsen wrote:
>
>> One one hand, having a single name saves clutter. I know I can use
>> the same code for all SCRAM varieties if they're defined using the
>> same words in the same document.
>>
>> On another, how many varieties are expected in the foreseeable
>> future? 1? 2? A generic mechanism that covers one or two cases has
>> bad karma, and one that is meant to cover the unforeseeable future
>> in cryptography and computer security has really awful karma.
>>

I have no objection to the current structure.  1) is good in that it
makes it easy to do a search-n-replace for SHA-1 with SHA-256 or SHA-3
when the need arise.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Nov 2008 22:33:00 +0100

Alexey Melnikov <[email-masked]> writes:

> I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1
> with IANA.

It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
and supported in SASL via GS2, the mechanism name registered with IANA
will be the GS2-* name, not SCRAM-HMAC-SHA-1.  Have we given up on
supporting SCRAM as a GSS-API mechanism?  That would be bad news for me,
I still see a long-term need for a password-based GSS-API mechanism.

The wire protocol changes to turn SCRAM into a GSS-API mechanism are
minimal: just the OID-prefix on the first message.  And a section
describing the GSS-API related semantics (prot-ready etc).

We could also let SCRAM move forward as a native SASL mechanism, write a
separate short document that says SCRAM plus OID-prefix and some
semantics is a password-based GSS-API mechanism.  The problem then is
how to deal with native SCRAM vs SCRAM-via-GS2.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Nov 2008 16:24:21 -0600

Simon Josefsson wrote:

>will be the GS2-* name, not SCRAM-HMAC-SHA-1.
>
That is correct.
But I wanted to resolve all outstanding issues except for GS2 framing 
and make the document self consistent.

>Have we given up on supporting SCRAM as a GSS-API mechanism?
>
No.

>That would be bad news for me,

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 Nov 2008 08:55:29 +0100

> and make the document self consistent.

Great.  To help the SCRAM document to prepare a GS2 name, here is text I
prepared, based on similar text for GS2+Krb5.  Someone needs to check
the computations, but that can happen later on.

X.Y SASL Mechanism Name for SCRAM

   The GSS-API OID for SCRAM is 1.3.6.1.4.1.11591.4.2 and its DER
   encoding is (in hex) 06 09 2B 06 01 04 01 DA 47 04 02.  The SHA-1
   hash is 29 06 29 12 AB 25 83 CD 02 92 1B 4E 2D D8 6A 40 CD D0 5D C2.
   Convert the first ten octets to binary, and re-group them in groups
   of 5, and convert them back to decimal, which results in these
   computations:

   hex:
   29 06 29 12 AB 25 83 CD 02 92

   binary:
   00101001 00000110 00101001 00010010 10101011
   00100101 10000011 11001101 00000010 10010010

   binary in groups of 5:
   00101 00100 00011 00010 10010 00100 10101 01011
   00100 10110 00001 11100 11010 00000 10100 10010

   decimal of each group:
   5 4 3 2 18 4 21 11 4 22 1 28 26 0 20 18

   base32 encoding:
   F E D C S E V L E W B 4 2 A U S

   The last step translate each decimal value using table 3 in Base32
   [RFC4648].  Thus the SASL mechanism name for SCRAM is
   "GS2-FEDCSEVLEWB42AUS".

/Simon

---

From: Chris Newman <[email-masked]>
Date: Fri, 21 Nov 2008 18:06:10 -0600

> describing the GSS-API related semantics (prot-ready etc).

If only it were that simple.  We're still evaluating doing SCRAM as GS2, 
but it looks like it adds an extra redundant hash computation for both ends 
and a bunch of cruft to every message.  I still think we should make it 
concrete to see if the result is palatable, but I can't predict if we'll 
get WG rough consensus on the result.

		- Chris

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Nov 2008 13:08:14 -0600

> and make the document self consistent.

I'm confused.  How does registering "SCRAM-HMAC-SHA-1" help with that?

Incidentally, there is the possibility of SASL/GS2 using names not
derived from hashing GSS mech OIDs, instead requiring registration
first.  I don't mind that, but it seems less flexible.

> >Have we given up on supporting SCRAM as a GSS-API mechanism?

Good.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Nov 2008 13:05:40 -0600

> >describing the GSS-API related semantics (prot-ready etc).

Only if we go with compression of that OID (which we should), though the
change then is slightly more involved, IIRC, but still in the realm of
the trivial.

As for implementations, the more significant are the changes to go from
meeting whatever requirements of a SASL implementation's plug-in SPI to
meeting the requirements of a GSS-API implementation's plug-in SPI, plus
-optionally- providing a true SASL/GS2 implementation.

> get WG rough consensus on the result.

Simon was talking about what it would take to get a GSS mechanism out of
a SCRAM specification based on SCRAM-as-a-SASL/GS2 mechanism that is not
described primarily as a GSS-API mechanism to begin with.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Nov 2008 14:16:31 -0600

> I don't see a reason to change the document.

I see Simon's issue as one bearing on: a) implementation details of
pluggable SASL frameworks, b) how easy it is to create variants of SCRAM
(just an IANA registration?  or a new RFC?).

With regard to (b), for variants of SCRAM differing from the original
SCRAM only in terms of which cryptographic algorithms are used, sure, an
IANA registration might be sufficient, while still allowing
registration-via-RFC- publication for variants that differ more
significantly.

As to (a), what component should be aware of and implement the
cryptographic algorithm pluggability of a mechanism family?  The SASL
mechglue?  Or the mechanism plug-ins to that mechglue?

I believe that question answers itself.  It should be the mechanism.  I
think it's possible that the SCRAM spec's wording might lead an
implementor astray, so it's worth discussing this implementation design
detail.

Think of a framework with a config file, say, /etc/sasl/mechs, which
lists {<mech-name>, <plug-in-object>}, with one plug-in object that
implements all variants of SCRAM.  As long as the plug-in interfaces
allow the plug-in to know the name of the mechanism it is implementing
at any given time then a signle object can very well implement all
variants of SCRAM.

An alternative design that makes the framework implement SCRAM's
pluggability might look like this: a config file, say, /etc/sasl/mech,
that lists {<mech-name>, <plug-in-object>, <algorithm-options>}, where
the mechglue passes the plug-in object a set of function/class/whatever
for the <algorithm-options> references instead of the <mech-name>.  Such
a design would clearly limit a plug-in implementor's freedom to
implement variants of SCRAM with a single plug-in object should a future
variant of SCRAM differ from today's in more ways than just which hash
function algorithm it uses.

As I said, I think the first implementation design is obviously the
better one.

The spec should not be written such that a SASL framework implementor
could be misled into thinking that the second design is the correct one.
Referring to SCRAM as a "mechanism family" might just do that.  But in
practice I doubt it.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Nov 2008 14:01:55 -0600

> Why does SCRAM needs to be defined as a mechanism family?

It doesn't have to be.  In fact, it shouldn't be in that a SASL mechglue
implementation should not be aware of it, even though the implementation
of the SCRAM mechanisms may well share so much common code as to be make
it a "mechanism family."

I.e., the "family" thing should be an implementation detail, not a
detail that binds us to today's SCRAM design when we go add a new hash
tomorrow.

> document and replacing SHA-1 with SHA-256 is possible.

No need to copy the doc, just have a new one with a normative reference
to the old one, with the new one saying "use the new OID/name and
SHA-256 instead of SHA-1."

> improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed

Absolutely.

> but I'd be interested to understand why it was added here.

I agree.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 11:05:51 +0100

> first.  I don't mind that, but it seems less flexible.

Good point.  If we, for some reason, want to retain the SCRAM-HMAC-SHA-1
SASL mech name even when SCRAM happens to be implemented as a GSS-API
mechanism, and supported in SASL via GS2, we could add an exception in
the GS2 document such as this:

  GS2 implementations MUST use the SCRAM-HMAC-SHA-1 mechanism name for
  the GSS-API mechanism with OID 1.3.6.1.4.1.11591.4.2.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 11:01:50 +0100

> change then is slightly more involved, IIRC, but still in the realm of

What do you mean by OID compression?

> -optionally- providing a true SASL/GS2 implementation.

Agreed, this will be the challenge.  I believe it is likely that
implementation feedback will result in some specification changes or new
specification further down the road.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 09:21:46 -0600

> What do you mean by OID compression?

Sam and I came up with an OID compression scheme for SASL/GS2 quite a
while ago as a way to make sure that implementors of SCRAM-as-a-pure-
SASL mech don't have to put on the wire that pseudo-ASN.1 header from
RFC2743 on initial context tokens.  I thought we'd discussed it on the
list and/or at IETF meetings.

Basically: you know the OID from the SASL mech name so there's no need
to put in that header.

A SASL/GS2 client implementation based on the GSS-API can recognize and
remove that header trivially.  (The code to do this exists in most every
GSS-API mechglue implementation, of which there are several open-source
ones.)

A SASL/GS2 server implementation based on the GSS-API will be able to
recover the OID from the SASL mech name (yes, the SASL mech name results
from applying a one way function to the mech's GSS OID, but there's a
very small set of GSS mech OIDs) and so will be able to re-create that
header prior to calling GSS_Accept_sec_context().  (The code to
create that headerexists in most every GSS-API mechglue implementation,
...)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 09:26:58 -0600

>   the GSS-API mechanism with OID 1.3.6.1.4.1.11591.4.2.

But we'd have so few exceptions that we might as well:

a) list them all now for all known GSS mechs
b) create a registry or expand the existing IANA SASL mech name registry

I don't think that'd suck, so why not?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 16:56:58 +0100

> create that headerexists in most every GSS-API mechglue implementation,

Ah.  Good idea, I had either forgotten about it or never heard of it.  I
believe GS2 needs to add some text about this naming truncation.  The
majority of the text that defines SCRAM as a GSS-API mechanism should
likely go into the SCRAM document though.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 17:03:59 +0100

> I don't think that'd suck, so why not?

I think it depends on whether we want to abandon the GS2-* naming scheme
altogether, and instead make the IANA SASL registry contain three
columns:

SASL mechanism name     Optional GSS-API mechanism OID    Reference

CRAM-MD5                                                  RFC 2095
SCRAM-HMAC-SHA-1        1.3.6.1.4.1.11591.4.2             RFC X
...

Then you need to register a SASL mechanism name for every GSS-API
mechanism you want to use in SASL via GS2 explicitly.

GS2 would then be responsible for adding/removing the GSS-API specific
OID-prefix in the first context token.  If a GS2 implementation does not
know how to map between a particular OID and a SASL mech name, it gives
up.

I would prefer this approach.  I think the B32(TRUNC(SHA1(DER(OID))))
approach is complex and ugly.

/Simon

---

From: Tom Yu <[email-masked]>
Date: Tue, 25 Nov 2008 10:59:25 -0500

> I don't think that'd suck, so why not?

Are you suggesting abandoning the OID-hash-based mech names for GS2 SASL
mechs?

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 10:01:34 -0600

> likely go into the SCRAM document though.

Glad you like it.  At first Sam and I thought it was a fairly radical
idea, but it grows on me, you don't object, and I doubt any of the
SCRAM-as-pure-SASL-mech implementors would object (as if!).  It's simple
enough and not really costly in terms of code for SCRAM-as-SASL/GS2
implementors, so let's do it.

Yes, much, if not all of the text that describes SCRAM-as-a-GSS-API-mech
should be in the main SCRAM doc.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 10:13:06 -0600

> altogether, and instead make the IANA SASL registry contain three

I am not a fan of hashing OIDs to make SASL mech names.

> SCRAM-HMAC-SHA-1        1.3.6.1.4.1.11591.4.2             RFC X

Yes.

> mechanism you want to use in SASL via GS2 explicitly.

Yes.  Registration rules should be light-weight.

> know how to map between a particular OID and a SASL mech name, it gives

Right.

> approach is complex and ugly.

Me too.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 10:14:04 -0600

> Are you suggesting abandoning the OID-hash-based mech names for GS2 SASL

I am.  I see that Simon likes that, and I suspect that Chris would be
ecstatic.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 22:09:32 +0100

> should be in the main SCRAM doc.

I'll prepare text to achieve this in the GS2 document.  It will require
some additional IANA considerations, but that shouldn't be too onerous.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 15:23:55 -0600

> some additional IANA considerations, but that shouldn't be too onerous.

Wait.

Sam has an objection to not deriving SASL/GS2 mech names from the OID of
the GSS mech.

Sam argues that that change would require updating SASL frameworks when
new GSS mechs become available.  And he's right.

Of course, for an operating system vendor/distro the preferred retort to
that would be that packages delivering GSS mechanism plug-ins should
update both, the gss mechglue and the sasl mechglue.

But that's not enough.  There's no reason that a third party couldn't
develop an application that implements its own SASL client framework,
say, and there exist apps that do just that.  Such apps would have to be
updated manually.  And that's not acceptable.

What we could do, however, is assign non-hash-derived SASL/GS2 mech
names to SCRAM and Kerberos V from the get-go, and use hash-derived
SASL/GS2 mech names for all other GSS mechs.  Just like SASL/GS1 did,
effectively.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 22:46:19 +0100

> SASL/GS2 mech names for all other GSS mechs.  Just like SASL/GS1 did,

Ok.  Then I don't think an IANA registry will work: how will you handle
negotiation of a future GSS-API mechanism X?  It won't be mentioned in
the GS2 document, so an initial GS2 implementation would not be aware of
it, and thus will use the hash-derived mech name.  If there is an IANA
registry, and some other GS2 implementation comes along that knows about
the SASL mech name registered for X, it won't interoperate with the
other GS2 implementation.

I guess the options are:

1) Never use hash-derived mech names.  Instead require that a SASL name
is registered for every GSS-API mechanism OID.

2) Use hash-derived mech names for "other" GSS-API mechanisms, but
mention the exceptions of SCRAM and KRBV5 in the GS2 document.

3) Always use hash-derived mech names.

Frankly, I don't see the benefit of 2).  It has all the complexity of
BOTH solutions and I don't see any advantages.

Well, ok, one minor advantage with 2) is that you will save 10-15 bytes
or so on the initial context token.  But bandwidth optimization doesn't
warrant complexity of this magnitude without benchmarks illustrating
bandwidth usage is the bottle-neck, in my opinion.

/Simon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Nov 2008 23:09:17 +0100

What are some applications that implement their own SASL framework, 
would need updates to support new SASL mechanisms, and would NOT need 
updates to support new SASL/GS2 mechanisms?

Anrt

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 16:08:06 -0600

> negotiation of a future GSS-API mechanism X?  It won't be mentioned in

You misunderstood.  I was saying what you say in option (2) below.

> BOTH solutions and I don't see any advantages.

It'd make SCRAM more palatable to pure SASL implementors, I suspect.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Nov 2008 23:37:23 +0100

> You misunderstood.  I was saying what you say in option (2) below.

Okay, but my 2) does not involve an IANA registry, and my point was that
an IANA registry for the names that would need to be mentioned
explicitly in GS2 does not work due to the future-mechanism negotiation
problem.

I think an IANA registry is only useful (and even compatible) together
with 1).

> It'd make SCRAM more palatable to pure SASL implementors, I suspect.

They aren't likely to use KRBV5, so let's reduce the list of explicit
mech's to mention explicitly to only SCRAM then.  If even that is
needed.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 16:38:18 -0600

> updates to support new SASL/GS2 mechanisms?

Today: none.

However, suppose you've written some application using GNU SASL
(libgsasl) and you want to build and run it on some operating system
where the system-provided SASL library is, say, Cyrus SASL (libsasl2).
You may not want to port to libsasl2.  You may want to just ship your
app linked with a private copy of libgsasl (which you'd also ship along
with your app).

Now, you can expect GSS mechanisms packaged and delivered by that
operating system's maintainers to update the GSS-API library's mechanism
registration and the SASL library's, but you can't expect them to update
your application's gsasl mechanism registration.

That was the example Sam gave me.  I think it's quite likely to happen.
I think it will be best to avoid it (i.e., Sam convinced me that at
least all future GSS-API mechanisms should have SASL/GS2 names derived
from their OIDs).  Sam did propose an alternative: extend the GSS-API to
provide a function for looking up a GSS mechanism's registered SASL/GS2
name, but I don't think anyone will be enthustiastic about that.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Nov 2008 00:16:16 +0100

> your application's gsasl mechanism registration.

What kind of application would be able to take advantage of the new
GSS-API mechanism?

Most SASL applications are rather tightly coupled with the SASL
mechanism in order to do auditing (logging), authorization,
leap-of-faith trust, and possibly other mechanism-specific operations.

If an application or SASL library notices that an unknown GSS-API
mechanism is available, I don't see how applications or SASL libraries
could use that mechanism without additional APIs that doesn't exist
today -- APIs such as "does this mechanism use X.509?" which would allow
the application to do something reasonable with the X.509 credentials.
Another API would be "does the mechanism uses passwords?", which would
allow the application and SASL library to treat it similar to existing
password mechanisms.

While nice in theory, I'm yet to be convinced that automatic support for
unknown GSS-API mechanisms in applications is something that is even
close to becoming a reality.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Nov 2008 17:30:52 -0600

> What kind of application would be able to take advantage of the new

CLient apps.

> leap-of-faith trust, and possibly other mechanism-specific operations.

Yes, but that's all server side.  Not that anything stops you from
writing a server app that uses GNU SASL on a system that ships with
Cyrus SASL, yet still use the system's GSS-API framework -- you'd just
not benefit from whatever integrated auditing, ... the system's SASL
framework provides.

> the application to do something reasonable with the X.509 credentials.

I think client apps would just work.  Much the same is true for simple
GSS apps.  E.g., I didn't have to add any mech-specific code to SunSSH to
make it use any GSS mech shipped with Solaris, though I did have to
hard-code SPNEGO's OID because SSHv2 w/ GSS is not allowed to use
SPNEGO and I had no better way to detect if a mechanism was SPNEGO.

Nico
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 26 Nov 2008 11:05:18 +0100

Nicolas Williams writes:
>>  would need updates to support new SASL mechanisms, and would NOT 
>>  need updates to support new SASL/GS2 mechanisms?
>
> Today: none.
>
> where the system-provided SASL library is, say, Cyrus SASL 
> (libsasl2). You may not want to port to libsasl2. You may want to 
> just ship your app linked with a private copy of libgsasl (which 
> you'd also ship along with your app).
>
> operating system's maintainers to update the GSS-API library's 
> mechanism registration and the SASL library's, but you can't expect 
> them to update your application's gsasl mechanism registration.

If my experience is anything to go by (FWIW I was a library person in a 
past life), then you also can't expect such application vendors to want 
to use new mechanisms.

Many of our customers who shipped private copies of libraries, and they 
generally wanted to use only what was in them, not anything more. For 
good reason.

> least all future GSS-API mechanisms should have SASL/GS2 names 
> derived from their OIDs). Sam did propose an alternative: extend the 
> GSS-API to provide a function for looking up a GSS mechanism's 
> registered SASL/GS2 name, but I don't think anyone will be 
> enthustiastic about that.

I don't see a lot of enthusiasm for the hashed names either.

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 26 Nov 2008 10:42:23 -0600

> generally wanted to use only what was in them, not anything more. For 

That was Sam's point -- the OS can provide SASL and GSS frameworks, but
there's no way to force third parties to use them.

Now, one possible answer is: not our problem.  But I don't like that
answer.

> I don't see a lot of enthusiasm for the hashed names either.

Ah, see, I knew that.  But a choice still has to be made.