Subject: A SASL/GSS-API bridge in the *other* direction?

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 00:45:08 -0600

It seems to me that we could pursue a SASL/GSS-API bridge in the
opposite direction of GS2, either in addition to or instead of GS2.

SASL mechanisms, SASL being stream-oriented, are not well-suited to be
being used as GSS-API mechanisms.  But perhaps there is a way.

Certainly, any SASL mechanism that provides channel binding could at
least be adapted as a GSS-API mechanism that provides channel binding
but no GSS-API per-message tokens.

But also, any SASL mechanism that could be made to provide session
keying for GSS-API per-message tokens could be used to key the per-
message tokens specified by RFC4121 (the Kerberos V GSS mech).  All we'd
need is the SASL equivalent of GSS_Pseudo_random() -- a SASL PRF.

Any SASL mechanism that uses cryptographic keys and has nonces could be
adapted to provide a "SASL PRF" [without changes to SASL apps] and so
any such mechanism could be used to build a GSS-API mechanism.  And any
SASL mechanism that can provide a SASL PRF can be used to provide both
GSS-API channel binding and GSS-API per-message tokens.

Is there any reason that a "SASL PRF" couldn't be constructed for
DIGEST-MD5, SCRAM, even CRAM-MD5?  I can't see one.  Are there any other
reasons why such a bridge would not be a good idea?  Principal naming
issues, perhaps?

Thus we'd use GS2 to use the Kerberos V and PKU2U GSS-API mechanisms in
SASL, and we'd use the bridge in the other direction to use DIGEST-MD5
and SCRAM in GSS-API applications.

If such a bridge is doable we could just adopt Chris' pure SASL SCRAM
without further ado.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 02 Mar 2009 09:50:09 +0000

>but no GSS-API per-message tokens.
Right.

>need is the SASL equivalent of GSS_Pseudo_random() -- a SASL PRF.
Indeed.

>any such mechanism could be used to build a GSS-API mechanism.
>
Right. I was thinking about doing something like this in relationship to 
TLS.

>And any SASL mechanism that can provide a SASL PRF can be used to provide both
>DIGEST-MD5, SCRAM, even CRAM-MD5?  I can't see one.
>
I can't think of any either.

>Are there any other reasons why such a bridge would not be a good idea?
>
No, go for it :-).

>Principal naming issues, perhaps?
>  
>
Can you elaborate?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 09:18:04 -0600

> Right. I was thinking about doing something like this in relationship to 

Could you expand?  Did you mean using TLS as a SASL mechanism?  Or SASL
in TLS?  The latter is going to run into the same problems that TLS-GSS
did; we did discuss that in a jabber room or three at one or more IETF
meetings.

> I can't think of any either.

OK.

Do you think that a SASL equivalent to RFC4401, and a DIGEST-MD5 and
SCRAM equivalent to RFC4402 is simple enough?

In order to keep round-trip counts down it's important to be able to
have equivalen support for GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL
prf_key values in the SASL PRF.  For password-based mechanisms that's
trivially done.

> >Principal naming issues, perhaps?

Well, I was reaching -- wondering if there might be anything in SASL
mechanisms' principal naming that might be fatal for such a bridge, but
I can't think of anything.  E.g., DIGEST-MD5's notion of realm, or the
fact that SCRAM doesn't have one, but neither is a problem w.r.t.
GSS-API principal naming.

> >If such a bridge is doable we could just adopt Chris' pure SASL SCRAM

I await additional comments, but I'm reasonably sure that such a bridge
is quite doable.  Mechanism naming could be done mechanically by
encoding each SASL mechanism's name as OIDs :)  For example:

 - "SCRAM"'s bridged OID might become (yes, I'm being real cute here,
   encoding every pair of letters as an OID label, though one needn't
   stop at two):

   {1(iso), 3(org), 6(dod), 1(internet), 5(security),
       21313(gss-bridged-sa), 21315(sc), 21057(ra), 77(m)}

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 19:18:32 -0500

> opposite direction of GS2, either in addition to or instead of GS2.

I don't think this is viable _instead of_ GS2; there are existing GSS-API 
mechanisms, Kerberos included, which we need to have available as SASL 
mechanisms.

I'm not sure it is viable _in addition to_ GS2, because it imposes a fairly 
signficiant new requirement on SASL mechanisms, namely that they provide a 
PRF.  Currently SASL mechanisms do not provide a PRF, no SASL applications 
use this feature, and I would not expect any new SASL applications to use 
this feature.  That means you're proposing that all new SASL mechanisms 
provide a feature which will likely not be tested or used during the 
development of the mechanism.

I suppose one could define a PRF separately for each new SASL mechanism, 
but then a bridge doesn't really gain you much.  You don't save the effort 
of specifying each mechanism separately for GSS, or of implementing, or of 
testing, and you don't give the users the ability to drop a new SASL 
mechanism into the existing framework and immediately start using it with 
GSS-API apps.  GS2 actually buys us all of these things, by building SASL 
mechanisms on top of features that every GSS-API mechanism (or at least, 
every useful one) already has, and that every new GSS-API mechanism will 
have.

I'm not even sure it is a good idea to do this instead of GS2 for the 
specific case of SCRAM.  We already basically have a SCRAM mechanism in the 
form of draft-newman-auth-scram.  We have reduced the bits added by GS2 to 
a pair of flags in the first message, one of which is constant, and the 
same two flags plus the mechanism name prefixed to the channel binding 
data.  I think that is quite simple enough for anyone.

Making SCRAM really usable as a GSS-API mechanism requires that we define a 
PRF, MIC tokens, and Wrap tokens.  These features are not used by GS2 and 
will never be used by SASL, so they can actually be defined in a separate 
document that need not even be read by SASL implementors.  A flag would 
likely be required to indicate that these features are supported, but the 
existing SCRAM message format already provides a suitable place for such a 
flag, in the form of an extension.

So, the benefit of recasting SCRAM in terms of a "reverse" bridge seems to 
be relatively low.  Now, let's look at the cost...

- It becomes necessary to define the PRF, not only for SCRAM but for
  every new SASL mechanism.
- It becomes necessary to implement and test the PRF, not only for SCRAM
  but for every new SASL mechanism.  Possibly single-app implementations
  can get away with this, but nothing resembling a library can.
- With bridges in both directions, we have to define complicated rules
  to prevent them from being composed.
- The reverse bridge document will never be completed, because no one
  has time to write it (I don't, Alexey doesn't, Nico doesn't).

Oh, and doing this would _not_ allow us to just adopt Chris's document 
as-is, because we'd still have to deal with the issue of supporting channel 
bindings, allowing them to be ignored if one or both sides can't support 
them, but detecting when both sides _can_ support them but a MITM attempts 
to prevent their use.  I think we've decided that's important, and it has 
to be solved even if we make SCRAM a pure SASL mechanism.  Of course, the 
solution wouldn't look much different from what we've devised for GS2, 
which in turn is very nearly the only thing GS2 adds to SCRAM's messages.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 18:23:17 -0600

> every useful one) already has, and that every new GSS-API mechanism will 

Thank you.  This is a key point.

> data.  I think that is quite simple enough for anyone.

I wasn't sure that the two mechanism names part would be simple enough
-- noone had spoken to that.

>  has time to write it (I don't, Alexey doesn't, Nico doesn't).

Thanks.  I agree.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 Mar 2009 08:46:47 +0000

Nicolas Williams wrote:

>>GSS-API apps.
I think It would be easier to define such bridge for each SASL mechanism 
that defines a security layer. (How ironic)
I certainly see no point in using CRAM-MD5 in GSS.

>>GS2 actually buys us all of these things, by building SASL 
I think we need more feedback on the final proposal before deciding.

>> can get away with this, but nothing resembling a library can.
I think my suggestion above addresses that.

>> to prevent them from being composed.
That is true.

>> has time to write it (I don't, Alexey doesn't, Nico doesn't).
Well, my time is running out either way. If I don't finish SCRAM during 
SF, then I might not have time to finish it.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 Mar 2009 09:58:54 +0000

>did; we did discuss that in a jabber room or three at one or more IETF
I was thinking about defining a bridge from SASL to TLS, so that SASL 
mechanisms can be used as authentication components in TLS.
So at the end of a successful SASL authentication a shared key would be 
created that can be used by TLS encryption.
For example SRP in TLS (I know it is a solved problem, but you should 
see what I wanted to do).

However I've realized that TLS negotiation typically happends before 
SASL, so that wouldn't work for many apps protocols.

>SCRAM equivalent to RFC4402 is simple enough?
I think that might be easy enough. I don't think there is a need to 
define RFC 4402 equivalent for every available SASL mechanism, but 
defining it for SCRAM and possible DIGEST-MD5 shouldn't be difficult.

>GSS-API principal naming.  
I don't think that this is going to be a problem for existing SASL 
mechanisms.
However, principal naming is SASL-mechanism-specific, so this statement 
is not going to be true in general.

>       21313(gss-bridged-sa), 21315(sc), 21057(ra), 77(m)}
:-)
Who owns 1(iso), 3(org), 6(dod), 1(internet), 5(security)?