Date: Sat, 01 Aug 1998 16:20:26 -0700
From: Jeff Hodges <Jeff.Hodges@Stanford.edu>
Newsgroups: netscape.server.directory
CC: Jeff.Hodges@Stanford.edu
Subject: Of NS DS and SASL-based Authentication - info and questions

For those interested in using SASL-based authentication with the Netscape
Directory server (NS DS), I've included an analysis I've just done on the
NS DS's SASL support below. There's a references section with URLs if you
don't know what SASL is, or need more info.

For NS DS Netscapers, there are some assertions and implied questions about 
the NS DS's SASL support, and also the C and Java 3.0 SDK's SASL support,
strewn thru the below text. It'd be great to know what you guys think
about this.

Thanks,

Jeff
- -- 
Jeff Hodges                                   Jeff.Hodges@Stanford.edu
Senior Technical Staff                          voice: +1 650 723 2452
Directory Services and PKI                        fax: +1 650 723 0908
Stanford University                   http://www.stanford.edu/~hodges/
- ----------------------------------------------------------------------

Subject: Re: Netscape LDAP SDK 3.0 SASL hooks
Date: Sat, 01 Aug 1998 14:35:36 -0700
From: Jeff.Hodges@Stanford.Edu
To: <a Stanford ITSS-internal distribution list>

> JeffL wrote:
> The 3.0 SDK documentation at
> 
> http://developer.netscape.com/docs/manuals/dirsdk/jsdk30/index.htm
> 
> says it now has hooks for users to implement various SASL auth
> mechanisms - might that help us?  Somebody more familiar with
> SASL and Kerb (and Java) might want to take a look and see if
> that's a place we could tie in.  The gateway was written against
> the v1.0 beta 2 SDK, but I'll grab and install the new one (and
> hope it's compatible) so the server's up to date.



I've spent some time looking into various angles of this stuff -- below's what 
I've found. Contents are...


1. On LDAPv2-style (non-SASL) and LDAPv3-style (SASL-based) Bind operations, 
and our overall approach

2. On Netscape Directory Server 3.0's Support for SASL-based Auth Plug-ins

3. On "Netscape Directory SDK 3.0 for C"'s Support for LDAPv2-style 
Kerberos-v4-based Auth and Generic SASL-based Auth

4. On "Netscape Directory SDK 3.0 for Java"'s Support for LDAPv2-style 
Kerberos-v4-based Auth and Generic SASL-based Auth

5. On the Availability of Source for "Netscape Directory SDK 3.0 for Java"

6. References

7. Background on SASL


The bottom line answer is that, IMHO, we should stick with LDAPv2-style 
Kerberos-v4-based Bind requests for the foreseeable future, and hack the 
Netscape server and SDKs as needed.


JeffH


- ---------------------------------------------------------------------------
1. On LDAPv2-style (non-SASL) and LDAPv3-style (SASL-based) Bind operations, 
and our overall approach

We are currently utilizing LDAPv2-style Kerberos-v4-based Binds. In these Bind 
requests, the selection of Kerberos as the auth mechanism, plus the client's 
service ticket, are carried directly in the Bind request itself.

Binding with Kerberos auth in LDAPv3 is via SASL negotiation. With SASL, the 
initial Bind request carries only the selection of SASL and the SASL 
mechanism (see section 6, below). An entire SASL-based negotiation may take 
several client<->server round-trips. For SASL-ized Kerberos v4, it is 
specified in RFC2222 to take three round-trips, not including the initial 
open-the-LDAP-conection-itself round-trip.

SASL-ized Kerberos (v4 or v5) is not presently being profiled for use with 
LDAPv3 in the IETF (precise reasons this is the case I don't fully understand, 
especially given NT 5.0's adoption of Kerberos). See..

  http://info.internet.isi.edu:80/in-drafts/files/
    draft-ietf-ldapext-authmeth-02.txt

This is not a huge deal in that it doesn't prevent anyone from implementing 
Kerberos auth with LDAP if they really want to, plus the Kerberos profiling 
can either be added to this doc at a later point in the standards process or a 
separate doc can be put forward. 

Note that an LDAPv3 Bind request is backwards-compatible with an LDAPv2 
Kerberos-based Bind request, because the requisite CHOICE values are set aside 
for this [RFC2251]...

        BindRequest ::= [APPLICATION 0] SEQUENCE {
                version                 INTEGER (1 .. 127),
                name                    LDAPDN,
                authentication          AuthenticationChoice }

        AuthenticationChoice ::= CHOICE {
                simple                  [0] OCTET STRING,
                                         -- 1 and 2 reserved <- for kerberos!!
                sasl                    [3] SaslCredentials }

        SaslCredentials ::= SEQUENCE {
                mechanism               LDAPString,
                credentials             OCTET STRING OPTIONAL }


It looks like we're going to have to customize both the client and server 
sides to get Kerberos at all (i.e. via either LDAPv2-style or SASL-based 
LDAPv3 Binds) using the Netscape Directory server and SDKs.

It seems to me that we will only need to support proper LDAPv3 SASL-ized 
Kerberos Bind operations if and when desirable off-the-shelf products appear 
that do such or if we come up with some reason, such as inter-institution 
auth'd directory access or whatever, that we need it.

Therefore, I think we should just do LDAPv2-style Kerberos Binds, even with 
LDAPv3-based apps, for the foreseeable future.

What we will have to have to make this happen with the NS DS...

	LDAPv2-style Kerberos v4 server-side plug-in that handles      done
	either LDAPv2 or v3 (non-SASL) Bind requests.

	LDAPv2-style Kerberos v4 client-side auth capability   	      !done
	in NSDirSDK3.0Java

	LDAPv2-style Kerberos v4 client-side auth capability          !done
	in NSDirSDK3.0C


Further details on these items are below.



2. On Netscape Directory Server 3.0's Support for SASL-based Auth Plug-ins

NSDir3.0 has the plug-in feature that we're already utilizing to accomplish 
the LDAPv2 Kerberos-flavored bind with either LDAPv2 or v3 binds [NSDS Prog, 
UMich Krb Plugin]. So, we can ostensibly use it, given the arguments above and 
modulo the issues with the SDK's, below.

Note that UMich terms their plug-in as a "SASL" plug-in, but it's actually
not.
Rather it is an LDAPv2-style Kerberos-v4-based authentication plug-in for 
inbound LDAPv2 or v3 connections.

In terms of doing legitimate SASL-based Binds to the NS DS in the future, 
it isn't clear that the plug-in architecture supports more than a
single client<->server round-trip. It looks like the definition of a 
Pre-Operation Bind Plug-In tacitly assumes that it'll be called by the client 
once.

But, it looks like the SLAPI_PLUGIN api does have a provision for a plug-in to 
save state in case it is invoked again -- a plug-in can allegedly save a 
pointer to some state in the SLAPI_PLUGIN_PRIVATE parameter of the 
Slapi_PBlock. Thus it ought to be possible for an invocation of a plug-in to 
check to see if there's any saved state and restore it and proceed 
accordingly -- IF SLAPI_PLUGIN_PRIVATE will allow an invocation of the plug-in 
to find the appropriate saved state from it's proper ancestor invocation. 
Whether this can be done isn't clear from the [NSDS Prog] doc. 

The only other apparent unanswered issue I see is from whence to alloc 
the state structure. Just do a malloc()? Or does the NS DS have more 
sophisticated memory management and is there some routine of its own that 
should be used?



3. On "Netscape Directory SDK 3.0 for C"'s Support for LDAPv2-style 
Kerberos-v4-based Auth and Generic SASL-based Auth

It doesn't seem that the NSDirSDK3.0C truly supports SASL-based Auth. This 
is because it provides a monolithic result-parsing function..

  #include <ldap.h>
  int ldap_parse_sasl_bind_result( LDAP *ld, LDAPMessage *res, 
     struct berval **servercredp, int freeit );

..that doesn't seem to have any provisions for the client to provide for 
interpretation of the server's challenge, or carrying out any further
client<->
server interactions, if needed by the chosen SASL mechanism.

Although the LDAPv2-style Kerberos-v4-based bind we're presently using is a 
single round-trip, the C SDK doesn't currently know how to form such a Bind. 
I've looked at the C SDK's code and it looks like we could reasonably hack 
support for it into the C SDK.


4. On "Netscape Directory SDK 3.0 for Java"'s Support for LDAPv2-style 
Kerberos-v4-based Auth and Generic SASL-based Auth

The NSDirSDK3.0Java appears to have the necessary features to enable arbitrary 
SASL negotiation exchanges with a server. However, as discussed in section 1, 
above, a SASL negotiation may comprise more than two client<->server 
round-trips. It isn't clear from the Java SDK doc [NS SDK Java] whether the 
netscape.ldap.LDAPConnection.authenticate method supports more than two round 
trips.

Additionally, as described above about the C SDK, support for LDAPv2-style 
Kerberos-based auth would undoubtedly have to be hacked in -- in the same 
manner that it will need to be in the C SDK. 



5. References

[NSD SDK C] Netscape Directory SDK 3.0 for C Beta 1 Programmer's Guide
http://developer.netscape.com/docs/manuals/dirsdk/csdk30/index.htm

[NSD SDK C] Netscape Directory SDK 3.0 for C Beta 1 Source
http://www.mozilla.org/directory/

[NSD SDK Java] Netscape Directory SDK 3.0 for Java Programmer's Guide
http://developer.netscape.com/docs/manuals/dirsdk/jsdk30/index.htm

[NSDS Prog] Netscape Directory Server Programmer's Guide 
http://developer.netscape.com/docs/manuals/directory/plugin/index.htm

[RFC2222] Simple Authentication and Security Layer (SASL)
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2222.txt

[RFC2251] Lightweight Directory Access Protocol (v3)
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2251.txt

[UMich Krb Plugin]
ftp://terminator.rs.itd.umich.edu/ldap/k4_sasl.tar.Z


6. Background on SASL

[RFC2222] defines a common approach to initiating authentication for 
connection-based protocols. SASL is roughly to protocols and their 
specifications as GSSAPI is to applications and their implementations.

Negotiation of SASL-initiated authentication mechanisms typically consists of 
at least two round trips between the client and server..


         client                                    server
           |                                         |
time       | "Open application-protocol connection   |
 |         |  on top of TCP"                         |
 |         +---------------------------------------->|
 |         |                                         |
 V         |                                         |
           | "Connection is opened"                  |
           |<----------------------------------------+
           |                                         |
           |                                         |
           |                                         |
  ---  --- | ----  -----  -----  -----  -----  ----- | ---  ----
    ^      |                                         |
    |      |                                         |
    |      |  "begin authentication, and let's use   |
    |      |   this XXX mechanism"                   |
    |      +---------------------------------------->|
    |      |                                         |
    |      |                                         |
    |      |  "Ok, I'll ~challenge~ you."            |
    |      |<----------------------------------------+
    |      |                                         |
    |      |                                         |
    |      |  "Here's my response, (sometimes)       |
    |      |   containing my credentials             |
    |      |   (depending upon selected mechanism)   |
    |      +---------------------------------------->|
    |      |                                         |
    |      |                                         |
    |                          .
 (SASL Negotiation             . [some number of messages,
  Happens Here)                .  from 0 to N, may be 
    |                          .  exchanged here in order 
    |                          .  to negotiate authentication
    |                          .  and optionally a security
    |                          .  layer.]
    |                          .
    |                          .
    |      |                                         |
    |      |                                         |
    |      |  "Ok, you're auth'd" (plus optionally:  |
    |      |  "and the security layer is set up")    |
    |      |<----------------------------------------+
    V      |                                         |
  ---  --- | ----  -----  -----  -----  -----  ----- | ---  ----
           |                                         |
           |                                         |
           V                                         V
                               .
                               . [client and server begin
                               .  communicating using the 
                               .  protocol, over the
                               .  the optionally secure
                               .  connection]
                               .
                               V

Where:

  XXX = KERBEROS_V4, CRAM_MD5, GSSAPI, SKEY, EXTERNAL, ANONYMOUS

  see: ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms


------- Forwarded Message #2


Date: Fri, 07 Aug 1998 16:40:41 -0700
From: Mark Smith <mcs@netscape.com>
Newsgroups: netscape.server.directory
To: Jeff Hodges <Jeff.Hodges@Stanford.edu>
Subject: Re: Of NS DS and SASL-based Authentication - info and questions

Jeff Hodges wrote:
> 
> For those interested in using SASL-based authentication with the Netscape
> Directory server (NS DS), I've included an analysis I've just done on the
> NS DS's SASL support below. There's a references section with URLs if you
> don't know what SASL is, or need more info.

Nice summary Jeff.  I embedded some of my own comments below.

-- 
Mark Smith
Directory Architect / Netscape Communications Corp.
My words are my own, not my employer's.  Got LDAP?


> ... 
> 2. On Netscape Directory Server 3.0's Support for SASL-based Auth Plug-ins
> 
> NSDir3.0 has the plug-in feature that we're already utilizing to accomplish
> the LDAPv2 Kerberos-flavored bind with either LDAPv2 or v3 binds [NSDS Prog,
> UMich Krb Plugin]. So, we can ostensibly use it, given the arguments above and
> modulo the issues with the SDK's, below.
> 
> Note that UMich terms their plug-in as a "SASL" plug-in, but it's actually
> not.
> Rather it is an LDAPv2-style Kerberos-v4-based authentication plug-in for
> inbound LDAPv2 or v3 connections.

Correct.

 
> In terms of doing legitimate SASL-based Binds to the NS DS in the future,
> it isn't clear that the plug-in architecture supports more than a
> single client<->server round-trip. It looks like the definition of a
> Pre-Operation Bind Plug-In tacitly assumes that it'll be called by the client
> once.

It does, but the support is not very explicit.  The best approach is
probably to keep some state information in your bind plugin.  This could
be a simple malloc'd table that is keyed by the connection id.

> .. 
> But, it looks like the SLAPI_PLUGIN api does have a provision for a plug-in to
> save state in case it is invoked again -- a plug-in can allegedly save a
> pointer to some state in the SLAPI_PLUGIN_PRIVATE parameter of the
> Slapi_PBlock. Thus it ought to be possible for an invocation of a plug-in to
> check to see if there's any saved state and restore it and proceed
> accordingly -- IF SLAPI_PLUGIN_PRIVATE will allow an invocation of the plug-in
> to find the appropriate saved state from it's proper ancestor invocation.
> Whether this can be done isn't clear from the [NSDS Prog] doc.

The problem is that I am pretty sure that the SLAPI_PLUGIN_PRIVATE field
is global to the plugin.  You need something that is per-connection
(which could, as I mentioned, be in the form of a table of some kind
your plugin maintains).  I don't know if anyone has actually tried this
yet though.


> The only other apparent unanswered issue I see is from whence to alloc
> the state structure. Just do a malloc()? Or does the NS DS have more
> sophisticated memory management and is there some routine of its own that
> should be used?

WAs long as you use thread safe calls you should be okay, but you might
as well use the memory allocation calls we provide as part of the SLAPI
API.  Scan slapi-plugin.h for the string "malloc".


 
> 3. On "Netscape Directory SDK 3.0 for C"'s Support for LDAPv2-style
> Kerberos-v4-based Auth and Generic SASL-based Auth
> 
> It doesn't seem that the NSDirSDK3.0C truly supports SASL-based Auth. This
> is because it provides a monolithic result-parsing function..
> 
>   #include <ldap.h>
>   int ldap_parse_sasl_bind_result( LDAP *ld, LDAPMessage *res,
>      struct berval **servercredp, int freeit );
> 
> ..that doesn't seem to have any provisions for the client to provide for
> interpretation of the server's challenge, or carrying out any further
> client<->
> server interactions, if needed by the chosen SASL mechanism.

This is incorrect.  You can perform as many round trips as you like. 
The server will send back the server credentials (placed in *servercredp
by ldap_parse_sasl_bind_result) and a result code of 14
(LDAP_SASL_BIND_IN_PROGRESS).  Applications -- or even better a small
layer you write to handle a specific kind of SASL bind -- can do
multiple ldap_sasl_bind() / ldap_parse_sasl_bind_result() pairs to
accomplish whatever credential passing is required by a SASL mechanism. 
Is there some reason this won't work?


> 4. On "Netscape Directory SDK 3.0 for Java"'s Support for LDAPv2-style
> Kerberos-v4-based Auth and Generic SASL-based Auth
> 
> The NSDirSDK3.0Java appears to have the necessary features to enable arbitrary
> SASL negotiation exchanges with a server. However, as discussed in section 1,
> above, a SASL negotiation may comprise more than two client<->server
> round-trips. It isn't clear from the Java SDK doc [NS SDK Java] whether the
> netscape.ldap.LDAPConnection.authenticate method supports more than two round
> trips.

Multiple round trips are supported through the SASLMechanismDriver
interface.  The documentation may be a little sketchy (I have not read
it all myself so I am not sure).  See:

 
http://developer.netscape.com/docs/manuals/dirsdk/jsdk30/intfsas2.htm#2833286

End of mcs' comments.

------- Forwarded Message #3

Date: Tue, 11 Aug 1998 11:54:36 -0700
From: Jeff Hodges <Jeff.Hodges@Stanford.edu>
Newsgroups: netscape.server.directory
To: Mark Smith <mcs@netscape.com>
Cc: Jeff.Hodges@Stanford.edu
Subject: Re: Of NS DS and SASL-based Authentication - info and questions

Mark Smith wrote:

> > In terms of doing legitimate SASL-based Binds to the NS DS in the future,
> > it isn't clear that the plug-in architecture supports more than a
> > single client<->server round-trip. It looks like the definition of a
> > Pre-Operation Bind Plug-In tacitly assumes that it'll be called by the client
> > once.
> 
> It does, but the support is not very explicit.  The best approach is
> probably to keep some state information in your bind plugin.  This could
> be a simple malloc'd table that is keyed by the connection id.
> 
> > ..
> > But, it looks like the SLAPI_PLUGIN api does have a provision for a plug-in to
> > save state in case it is invoked again -- a plug-in can allegedly save a
> > pointer to some state in the SLAPI_PLUGIN_PRIVATE parameter of the
> > Slapi_PBlock. Thus it ought to be possible for an invocation of a plug-in to
> > check to see if there's any saved state and restore it and proceed
> > accordingly -- IF SLAPI_PLUGIN_PRIVATE will allow an invocation of the plug-in
> > to find the appropriate saved state from it's proper ancestor invocation.
> > Whether this can be done isn't clear from the [NSDS Prog] doc.
> 
> The problem is that I am pretty sure that the SLAPI_PLUGIN_PRIVATE field
> is global to the plugin.  You need something that is per-connection
> (which could, as I mentioned, be in the form of a table of some kind
> your plugin maintains).  I don't know if anyone has actually tried this
> yet though.

So, it seems that the way to do this is to use the SLAPI_PLUGIN_PRIVATE field
to store a pointer to a table maintained by the plug-in (probably initially
alloc'd at init time), indexed by connection-id, as you suggest. Should use
slapi_ch_malloc() & Co. for memory mgmt. 

Make sense?


> > 3. On "Netscape Directory SDK 3.0 for C"'s Support for LDAPv2-style
> > Kerberos-v4-based Auth and Generic SASL-based Auth
> >
> > It doesn't seem that the NSDirSDK3.0C truly supports SASL-based Auth. This
> > is because it provides a monolithic result-parsing function..
> >
> >   #include <ldap.h>
> >   int ldap_parse_sasl_bind_result( LDAP *ld, LDAPMessage *res,
> >      struct berval **servercredp, int freeit );
> >
> > ..that doesn't seem to have any provisions for the client to provide for
> > interpretation of the server's challenge, or carrying out any further
> > client<->
> > server interactions, if needed by the chosen SASL mechanism.
> 
> This is incorrect.  You can perform as many round trips as you like.
> The server will send back the server credentials (placed in *servercredp
> by ldap_parse_sasl_bind_result) and a result code of 14
> (LDAP_SASL_BIND_IN_PROGRESS).  Applications -- or even better a small
> layer you write to handle a specific kind of SASL bind -- can do
> multiple ldap_sasl_bind() / ldap_parse_sasl_bind_result() pairs to
> accomplish whatever credential passing is required by a SASL mechanism.
> Is there some reason this won't work?


It sounds like it will work. The issue is more that..

  http://developer.netscape.com/docs/manuals/dirsdk/csdk30/sasl.htm

..is unclear about the above being possible. 


> > 4. On "Netscape Directory SDK 3.0 for Java"'s Support for LDAPv2-style
> > Kerberos-v4-based Auth and Generic SASL-based Auth
> >
> > The NSDirSDK3.0Java appears to have the necessary features to enable arbitrary
> > SASL negotiation exchanges with a server. However, as discussed in section 1,
> > above, a SASL negotiation may comprise more than two client<->server
> > round-trips. It isn't clear from the Java SDK doc [NS SDK Java] whether the
> > netscape.ldap.LDAPConnection.authenticate method supports more than two round
> > trips.
> 
> Multiple round trips are supported through the SASLMechanismDriver
> interface.  The documentation may be a little sketchy (I have not read
> it all myself so I am not sure).  See:
> 
> 
> http://developer.netscape.com/docs/manuals/dirsdk/jsdk30/intfsas2.htm#2833286

That page you reference is clear about multiple round trips being supported,
thanks. That page is the gnarly interface documentation itself. The page that
is not clear is..

http://developer.netscape.com/docs/manuals/dirsdk/jsdk30/sasl.htm#2848941
  Subsection entitled "Defining Your Own SASL Mechanism Drivers"

..which is part of the programmer's manual proper.



Thanks for your clarifications,

Jeff

------- End of Forwarded Messages