Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected]

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jul 2004 13:10:30 -0700

[with correct Last Call close date --Kdz]

This message initiates a SASL Working Group Last Call on the
document:

Title: 
Simple Authentication and Security Layer (SASL)

Editor: 
A. Melnikov

Filename: draft-ietf-sasl-rfc2222bis-08.txt

The purpose of this WG Last Call is to ensure that the Working
Group has achieved consensus that the document is suitable for
publication as a Proposed Standard.

Please review the document for both technical and editorial
problems.  Technical issues should be discussed on this list.
Editorial issues may be sent to the document editor.  If
after completing your review you find no issues, please
indicate so to the chairs.

The Last Call period will close on Friday, 13 August 2004.

Upon completion of the last call, the WG chair(s) will take
action based upon the consensus of the WG.  Possible actions
include:

  1) recommending to the IETF Security Area Directors
     that the document, after possible editorial or
     other minor changes, be considered by the IESG
     for publication as a Standard Track RFC
     (which generally involves an IETF-wide Last Call); or

  2) requiring that outstanding issues be adequately
     addressed prior to further action (including,
     possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members
to ensure the quality of our documents and of the Internet
Standards process.  So, please read and comment!

Kurt Zeilenga, SASL WG co-chair

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 16:46:21 -0500

> Filename: draft-ietf-sasl-rfc2222bis-08.txt

Your timing is convenient.  I have recently come to realize that neither
rfc2222 nor the rfc2222bis I-D say much, if anything, about re-keying of
security layers.  Perhaps I'm missing something.

It's also pretty clear to me that SASL mechanisms cannot re-key security
layers without application involvement (at least if using any SASL APIs
that require that the application use per-message/buffer security layer
calls).

Section 6.3 of rfc2222bis (and 5.3 of rfc2222) seems to obliquely
address this by mentioning multiple authentications and replacing old
security layers with new ones, which is, almost, exactly how I would
expect SASL apps to re-key (see below).

I propose the following changes to rfc2222bis:

 - Explicitly state that there is no security layer re-keying facility.

   (Alternatively design such a facility and add it to rfc2222bis; I
   don't like this alternative myself, mostly because it would require
   updating all the SASL mechanisms to specify re-keying and because
   either way the application must be involved in the re-keying process,
   so this alternative buys us nothing.)

   If re-keying be done by re-authenticating and negotiating new
   security layers (as in section 6.3 of rfc2222bis) then presumably the
   authenticated identities should remain the same(!).

 - Add security considerations text about security layer expiration due
   to passage of time, use of cryptographic material, administrative
   policies (e.g., credentials expiration).

   Consider the text of draft-ietf-secsh-newmodes, for example; the
   details of layer expiration typically will vary by SASL mechanism,
   but the underlying rationales (e.g., defense against cryptanalysis)
   should hold across the board.

 - Add a requirement that SASL mechanisms provide indications of
   security layer expiration to applications.  Security layer expiration
   should probably have advisory and mandatory modes (advisory primarily
   for applications that lack support for re-negotiating security
   layers).

 - Add a recommendation that all SASL applications (e.g., SMTP, SUBMIT,
   LDAP) specify how to replace old SASL security layers with new ones.

 - If section 6.3 was meant for any purpose other than re-keying then
   please clarify it.  For example, if an application authenticates as
   one identity, then switches to another and re-authenticates,
   presumably it should not act (or be allowed to, by its peer) on
   behalf of the first identity while using the second security layer,
   at least for some mechanisms.

Additionally, where IETF documents specify application protocol use of
SASL it would be nice to have clarifications/extensions for
re-negotiation of SASL security layers -- that is, re-keying.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jul 2004 11:44:58 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas>  - Add security considerations text about security layer
    Nicolas> expiration due to passage of time, use of cryptographic
    Nicolas> material, administrative policies (e.g., credentials
    Nicolas> expiration).

    Nicolas>    Consider the text of draft-ietf-secsh-newmodes, for
    Nicolas> example; the details of layer expiration typically will
    Nicolas> vary by SASL mechanism, but the underlying rationales
    Nicolas> (e.g., defense against cryptanalysis) should hold across
    Nicolas> the board.

Nico has a point.  The security ADs seem to care a fair bit about key
reuse.  Given that the issue has been brought up, I'd expect a discuss
if we don't at least address it in security considerations.  At a
minimum we need to discuss the fact that security layers can exceed
their key lifetimes and give guidance to application designers.

--Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Jul 2004 15:49:52 +0100

>that require that the application use per-message/buffer security layer
As a developer, I am not sure I agree. At least I can imagine how this 
can be done automatically.

>expect SASL apps to re-key (see below).
No, reauthentication is not the same as re-keying. The client may choose 
to reauthenticate as a different user, for example if the client is some 
kind of a proxy.

> - Explicitly state that there is no security layer re-keying facility.
Yes. But I would like to add instead that "there is no generic security 
layer re-keying facility", as each SASL mechanism that support a 
security layer is free to implement own re-keying.

>   so this alternative buys us nothing.)
I don't like this either, for the same reasons.

>   should hold across the board.
I would appreciate if you can send some text to me.

>   security layer expiration to applications.  
>
We can't make this a requirement, as support for a security layer is an 
optional feature of SASL framework.
But we can make this as a recommendation.

>Security layer expiration
This wouldn't be possible, as not all protocols support reauthentication.

>   one identity, then switches to another and re-authenticates,
Yes.

>   at least for some mechanisms.
Can you suggest some text?

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2004 10:29:01 -0500

> can be done automatically.

What do you not agree with?  The case described in the parenthetical
expression above cannot have automatic re-keying without changing the
existing APIs.  We've been over this, with respect to the GSS-API, at
either the old CAT WG list or at the KRB WG list a year or two ago.

> to reauthenticate as a different user, for example if the client is some 

RFC2222 and rfc222bis are mighty clear that re-authentication that
negotiates new security layers leads to replacement of the old layers
with the new ones.  Re-authenticate the same identities while
negotiating new layers and you've got re-keying.

IPsec w/ IKEv1 handles re-keying by establishing brand new SAs (for the
same IDs).

ONC RPC w/ RPCSEC_GSS (and, therefore, NFS) handles re-keying the same
way, namely, by establishing new GSS-API security contexts (for the same
names).  (This is actually very implicit, rather than explicit, in the
RPCSEC_GSS spec; what happens is that a GSS sec. context is needed only
for the life of an actual RPC, but RPC apps, like NFS, typically make
many RPCs and authorize peers on each call by inspecting the peer's GSS
name.  Today I would want the spec to be explicit about re-keying.  This
is, in fact, my attitude to SASL and re-keying.)

IPsec w/ IKEv2 can re-key IKE_SAs during their lifetime, but if those
expire it reverts to IPsec w/ IKEv1 re-keying behaviour.

SSHv2 supports true re-keying, rather than re-keying by
re-authentication.  But if you use the GSS-API-protected SSHv2 key
exchange to re-key SSHv2 connections then you also re-authenticate.

I think there's a well established tradition of re-keying by
re-authenticating the same identities where possible.

> security layer is free to implement own re-keying.

See my note above; some SASL APIs will require changes to support
re-keying with such mechanisms.  I'm pretty sure that the Cyrus SASL API
would, for example.

And existing SASL mechanisms do not support re-keying, leaving us with
re-keying-by-re-authenticating as the only simple alternative, an
alternative for which there is a fine tradition.

> I would appreciate if you can send some text to me.

Generic text for rfc2222bis?  I can do that.

> But we can make this as a recommendation.

Nonsense.  You can make this mandatory, for new and revised mechanisms,
where security layer support is available.  The SASL GSS mechanisms can
provide this today, since the GSS-API provides for context expiration.

And note that infinite and, possibly, unspecified security layer
lifetimes should be legitimate values for security layer expiration.

> This wouldn't be possible, as not all protocols support reauthentication.

But new ones could.  It's not at all clear to me that SMTP/SUBMIT don't
support re-authentication, for example.  I'm not sure whether this WG
can clarify that, but it can clarify that _new_ application protocols
that use SASL must support re-authentication, and thus re-keying.

We can go back and update the application protocol specs where lack of
re-authentication/re-keying hurts -- later.  First we need rfc2222bis to
say something about the matter.

> Can you suggest some text?

No, I cannot.  This WG should discuss and come up with this
clarification.  I can send you text on re-keying, but perhaps we should
see where the WG looks to be heading on that matter.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2004 10:48:46 -0500

> that use SASL must support re-authentication, and thus re-keying.

Actually, rfc2554 is quite clear that it is not possible to
re-authenticate in the SMTP/SUBMIT protocols.  This is unfortunate.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 16:46:21 -0500

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jul 2004 11:44:58 -0400

--Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Jul 2004 15:49:52 +0100

Yes.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2004 10:29:01 -0500

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2004 10:48:46 -0500

Nico
--