Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-09.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 09 Nov 2004 15:46:53 +0000

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>
>	Title		: Simple Authentication and Security Layer (SASL)
>	Author(s)	: A. Melnikov
>	Filename	: draft-ietf-sasl-rfc2222bis-09.txt
>	Pages		: 11
>	Date		: 2004-10-27
>	
>The Simple Authentication and Security Layer (SASL) is a framework
>   for providing authentication and data security services in
>   connection-oriented protocols via replaceable mechanisms. It provides
>   a structured interface between protocols and mechanisms.  The
>   resulting framework allows new protocols to reuse existing mechanisms
>   and allows old protocols to make use of new mechanisms.  The
>   framework also provides a protocol for securing subsequent protocol
>   exchanges within a data security layer.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-09.txt
>
>  
>
Hi everyone,
I don't think there is a point of providing a detailed list of changes from -08, as this is going to be a huge list. I think I've incorporated most of the editorial suggestions by Nicolas, Kurt and Hallvard, as well as addressed most of the Last Call issues. The remaining Last Call issues are described below:

1). Section 3.2. (Identity Concepts) needs review.

In particular text about normalization:

   Any normalization of the authentication identity (for the purposes
   of conducting authentication exchange) is defined by a particular
   SASL mechanism, the protocol profile doesn't influence it.
   Note, that the mechanism specification doesn't control how
   authentication identity information is represented elsewhere
   <<need to add few examples>>.

   The mechanism MUST preserve Unicode codepoints when transferring
   authorization identity (e.g. the mechanism can't apply any form
   of normalization).

The following text was lost in -09:

  The authorization identity is made available to further server
  processing for use in making access policy decisions.  The provision
  of additional client attributes that may affect access policy is not
  covered by this specification.

I think it falls under <<need to add few examples>>

2). In Section 5 (Mechanism profile guidelines) I've added text about re-keying. There is the original Nico's version of the text as well as mine (rewrite of Nico's text, hopefully it is clearer).

   6) SASL does not provide for re-keying (see Section 9.1), but SASL
      mechanisms may.

   <<Original Nico's text follows:>>
   SASL mechanisms that support re-keying SHOULD:
    - indicate that re-keying is or will be needed immediately;
    - provide re-keying messages or transparently include re-keying
      messages in the security layers; the latter can happen without
      application involvement, but only as long as the application is
      engaged in timely bidirectional exchanges with its peer.

   <<Alternative text by Alexey:>>
   A SASL mechanism supports re-keying if it is able to generate/process
   messages that request immediate re-keying and it is able to carry out
   re-keying exchange. (Note that the mechanism MAY use a single message
   type to do both). SASL mechanisms that support re-keying MAY also be
   able to indicate that re-keying will be needed in the future.
   A re-keying exchange can be conducted transparently by the mechanism,
   or the mechanism should be able to provide/accept re-keying messages
   to/from the application. The former can happen without application
   involvement, but only as long as the application is engaged in timely
   bidirectional exchanges with its peer.

3). Text in Section 9.1. (Re-keying) needs review. In particular text in <<>>. Do we need to keep it? Does it have to be 

   The secure or administratively permitted lifetimes of SASL
   mechanisms' security layers are finite.  Cryptographic keys weaken as
   they are used and as time passes; the more time and/or ciphertext
   that a cryptanalyst has after the first use of the a key, the easier
   it is for the cryptanalyst to mount attacks on the key.

   Administrative limits on security layers lifetime may take the form
   of time limits expressed in x.509 certificates, Kerberos V tickets,
   or in directories, and are often desired.  <<In practice one likely
   effect of administrative security layers lifetime limits is that
   applications may find that security layers stop working in the middle
   of application protocol operation, such as, perhaps, during large
   data transfers.  As the result of this the connection will be closed
   (see section 3.3), which will result in unpleasant user experience.>>

   Re-keying (key renegotiation process) is a way of addressing the
   weakening of cryptographic keys. SASL framework does not provide for
   re-keying.  SASL mechanisms may; all future SASL mechanisms that
   provide security layers should provide for re-keying.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 09 Nov 2004 15:46:53 +0000

Hi everyone,

Alexey