Subject: Re: Comments on the SASL C API

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Jul 2003 18:38:12 -0600

Simon Josefsson wrote:

> ...

I've added some clarification about multiple SASL tokens in sasl_decode as
described by Larry.

> Extension:

> Here is a writeup on an idea I have received.  It might cause some
> complications and likely needs more pondering.  However, if the
> rationale for adding this makes sense to you, I'd appreciate if you
> spent the time incorporating the functions.  If you are familiar with
> the GSS-API, compare this to the gss_export_sec_context and
> gss_import_sec_context functions that were added to GSS-API version 2
> (see RFC 2744).

I like the idea and had though about something similar myself. The question
is if this belong to the base SASL API document or should this be an
extension.

I would like to hear what other people think about adding this.

>  5.2.   Exporting and importing security layer state
>
>       Some application environments wishes to separate the initial and
>       short authentication step from the potentially long lived
>       application step, where the application uses sasl_encode() and
>       sasl_decode() to transfer application data.  This separation may
>       be between processes (separation across hosts is more
>       complicated, as the security layer state is often dependent on
>       the host address, but still conceivable).  The reason for such
>       separation may be to guarantee that long-term secrets (e.g.,
>       passwords) cannot be recovered by compromising the application
>       that handles existing session.
>
>       The functions defined in this section allows the application to
>       export the security layer state associated with a session as an
>       opaque character string, and later import the opaque character
>       string.  The opaque state typically contains an encryption key,
>       initialization vectors, what encryption algorithm to use, packet
>       number etc.
>
>   5.2.1. sasl_export_security_layer_state function
>
> Arguments:
>             sasl_conn_t *conn,
>             const char **state,
>             unsigned int *statelen
>
> Results:
>             SASL_OK        -- Success
>             SASL_NOTDONE   -- Security layer negotiation not finished
>
>       This function exports the security layer state required to
>       implement the sasl_encode() and sasl_decode() functions after
>       the state has been imported.  The security layer state is an
>       opaque data string.  The state and statelen are filled in with
>       the opaque state data and its length respectively. If the
>       security layer negotiation has not finished, SASL_NOTDONE is
>       returned.  After calling this function, the application should
>       treat the SASL session as concluded and call sasl_dispose().  In
>       particular, the application MUST NOT call sasl_encode() or
>       sasl_decode() [XXX sasl_dencode should simply return a error
>       code when it happens].  The state data is only valid until a
>       call to sasl_dispose(), and should be copied before calling
>       sasl_dipose() if necessary.
>
>   5.2.2. sasl_import_security_layer_state function
>
> Arguments:
>             const char *state,
>             unsigned int statelen
>             sasl_conn_t **conn,
>
> Results:
>             SASL_OK        -- Success
>             SASL_BADPARAM  -- Invalid parameter supplied
>
>       This function create a SASL session, for use with sasl_encode(),
>       sasl_decode() and sasl_dispose() only, from the given security
>       layer state.  The security layer state is an opaque data string,
>       as returned from sasl_export_security_layer_state().

Cheers,
Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 03 Jul 2003 05:30:06 +0200

> I've added some clarification about multiple SASL tokens in sasl_decode as

Thank you, and also to Greg and Larry who provided insight.  The
problem had a simple solution, but it wasn't really obvious [to me],
so additional text would not hurt.  Perhaps it can even be useful to
application writers, so they know sasl_decode() could return data that
is the concatenation of output from more than one call to
sasl_encode().  It appears that this could affect the choice of buffer
sizes.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Jul 2003 07:32:39 -0600

> sasl_encode().  It appears that this could affect the choice of buffer

sasl_decode allocates or returns own buffer, so the caller shouldn't worry about
buffer sizes.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Jul 2003 18:38:12 -0600

Cheers,
Alexey

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 03 Jul 2003 05:30:06 +0200

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Jul 2003 07:32:39 -0600

Alexey