Subject: GSS-API channel bindings

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 Jul 2004 09:51:09 +0200

There is a requirement that the GSS-API channel bindings are NULL.
I'd feel more comfortable if there was a way to somehow make use of
channel bindings, to link the authentication to the specific channel.
Does anyone have ideas on whether to add this, and if the answer is
positive, how it might be done?

I understand that the simplest "solution", from the SASL mechanism
point of view, might simply be to consider GSS-API mechanisms, that
doesn't link gss_wrap/gss_get_mic tokens with one specific
authentication, as broken.  However, channel bindings are provided by
GSS-API to enable applications to close this hole, hence these GSS-API
mechanisms can probably not be viewed as broken in general.  So it is
unfortunate that the SASL wrapping of GSS-API forbid channel bindings.
I'd say this warrant a paragraph in the security section, unless the
text about channel bindings is loosened up.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Jul 2004 13:28:07 -0500

> positive, how it might be done?

1.  Existing GSS-API mechanisms fail to correctly deal with channel
    bindings.  E.g., SPKM is way underspaecified in general, and here
    specifically; also, the Kerberos V mechanism does not have a way for
    the acceptor to prove to the initiator that it too has the same
    channel bindings as the initiator.

2.  We're trying to address this through a stackable pseudo-mechanism
    (CCM-BIND) one of whose purposes is to address this problem.  See:

    draft-ietf-nfsv4-ccm-03.txt

3.  The whole subject of channel bindings needs further specification.
    I'm about to submit a new version of

    draft-ietf-nfsv4-channel-bindings (-01.txt)

    that does this and which describes what goes into the channel
    bindings for SSHv2, TLS and IPsec channels, and then I'll submit

    draft-williams-gssapi-channel-bindings-00.txt

    for the KITTEN BoF (and, hopefully, WG), which fills in the details
    of how to use channel bindings to SSHv2, TLS and IPsec channels with
    the GSS-API.  The deadline for filing new I-Ds has passed though, so
    this won't get posted to the I-D repository until after this
    meeting.

4.  Given CCM-BIND and the two other drafts it should be possible to use
    SASL with GSS-API channel bindings; SASL APIs will have to be
    modified so the application can provide the necessary channel
    information.

5.  I have proposed a set of interfaces for determining the features of
    GSS mechs, as part of a framework for stackable pseudo-mechanisms,
    which should help GSS apps avoid having to hardcode mechanism OIDs
    and information about them (e.g., "channel bindings work well with
    this mechanism, but not with that one").

    See:

    draft-williams-gssapi-stackable-pseudo-mechs-00.txt

As you can see, there's a lot of activity around this topic.

> text about channel bindings is loosened up.

The SASL handling of GSS-API mechanisms does need some tweaking, both,
in light of the above and to provide for re-keying (GSS-API contexts can
expire, after all) by reestablishing GSS security contexts for the
principals involved.

Cheers,

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 27 Jul 2004 20:54:01 +0200

Nicolas Williams <[email-masked]> writes:

...
> As you can see, there's a lot of activity around this topic.

Thanks for this useful overview of activities.

> expire, after all) by reestablishing GSS security contexts for the

Do you have any thoughts on how to modify the SASL GSSAPI mechanism so
it is possible for it to use non-NULL channel bindings automatically?

The most simplistic solution is to permit non-NULL channel bindings in
the specification, and leave everything up to application protocols.

However, that approach require application protocol implementations to
tell the SASL library what GSSAPI channel bindings it wants.  While
this is feasible, perhaps it can be made even better.

What I'm trying to understand, is whether the SASL GSSAPI mechanism,
by itself, could construct the actual channel binding, and use it at
both ends.

(Some application might want to provide the channel binding data
themselves, so the above should only be a possible default behaviour,
in order to bind SASL GSSAPI authentication to a specific channel.)

Regards,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2004 15:20:28 -0500

> Thanks for this useful overview of activities.

NP.

[...]
> it is possible for it to use non-NULL channel bindings automatically?

See the CCM I-D in the NFSv4 WG and my personal I-D on stackable GSS
pseudo-mechanisms, which is due to be a WG I-D for KITTEN, if the KITTEN
BoF (which will meet this Monday) succeeds.

The short answer is that by negotiating the use of CCM-BIND apps also
negotiate the use of channel bindings.

CCM-BIND is a stackable pseudo-mechanism which is primarily intended for
these two purposes:

 - properly implement channel bindings the (the krb5 and spkm mechs
   don't)

 - indicate, in mechanism negotiations, the willingness to use channe
   bindings

Applications shouldn't offer or accept CCM mechanisms in their
negotiations if they have no useful channel to bind to.

The flip side is that apps SHOULD offer and/or accept CCM mechanisms in
their negotiations if they do have such channels and bindings and want
to use channel bindings.

> the specification, and leave everything up to application protocols.

See above.  This could work, but, the incomplete channel bindings
support in the Kerberos V and SPKM GSS mechanisms, and the additional
complexity for application protocols argues for the approach I offer
instead, namely to leverage existing mechanism negotiations in
application protocols to negotiate the use of channel bindings by using
mechanism OIDs which indicate the desire to do so.

> this is feasible, perhaps it can be made even better.

And requires changes to the application protocol to properly negotiate
the use of channel bindings.  The approach I offer does not.

> by itself, could construct the actual channel binding, and use it at

No, it cannot, but I have an I-D, which did not make the cutoff for new
I-Ds which specifies channel bindings constructor interfaces that make
this task easy for application developers.

> in order to bind SASL GSSAPI authentication to a specific channel.)

Of course.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 2004 20:21:00 +0100

>by itself, could construct the actual channel binding, and use it at
CMU SASL API allows applications to pass IP/port number of the both 
endpoints to the SASL library. It seems that this is sufficient to 
construct proper channel binding information? (Just thinking aloud).

Also, if either the client or the server end uses non null channel 
binding and the other end doesn't, will they be able to authenticate?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Jul 2004 14:56:32 -0500

> construct proper channel binding information? (Just thinking aloud).

No, it's not enough because there's no cryptographic binding there,
direct or indirect.

Throw in authenticated and "latched" IPsec IDs and you've got strong
bindings.

Or, if you're running over a TLS channel, throw in the TLS finished
messages.  Or, if you're running over an SSHv2 channel, throw in the
SSHv2 session ID.

> binding and the other end doesn't, will they be able to authenticate?

With the GSS-API?  Technically they shouldn't, though the krb5 mech has
some warts in this area (I won't describe them here).

The point is: GSS-API channel bindings are not negotiated by the GSS
mechanisms, so both peers must know a priori that both have or don't
have channel bindings.  Thus my comments earlier about CCM-BIND and
negotiation of the use of GSS mechanisms specifically designed to signal
and implement the use of channel bindings.

Please see draft-ietf-nfsv4-channel-bindings-02.txt.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 Jul 2004 09:51:09 +0200

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Jul 2004 13:28:07 -0500

See:

Cheers,

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 27 Jul 2004 20:54:01 +0200

...

Regards,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Jul 2004 15:20:28 -0500

NP.

[...]

Of course.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 2004 20:21:00 +0100

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Jul 2004 14:56:32 -0500

Nico
-- 

Date: Thu, 29 Jul 2004 14:56:32 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: GSS-API channel bindings
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

Nico
-- 

Date: Thu, 29 Jul 2004 20:21:00 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: GSS-API channel bindings
Sender: [email-masked]

Date: Tue, 27 Jul 2004 15:20:28 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: GSS-API channel bindings
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

NP.

[...]

Of course.

Nico
-- 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: GSS-API channel bindings
Date: Tue, 27 Jul 2004 20:54:01 +0200
Lines: 42
Cancel-Lock: sha1:8lfckb0bwOCEgjYbavs0poCWWNE=
Sender: [email-masked]

...

Regards,
Simon

Date: Tue, 27 Jul 2004 14:22:22 -0400
From: Jeffrey Altman <[email-masked]>
Organization: No Longer Affiliated with Columbia University in the City of New York
To: [email-masked]
CC: Kerberos WG <[email-masked]>, SASL WG <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Kitten (Common Authentication Technologies - Next Generation) at IETF 60
Sender: [email-masked]

The Common Authentication Technologies Next Generation (Kitten) BOF will 
be meeting at IETF 60:

1530-1730 Afternoon Sessions II
Grande B    SEC   kitten    Kitten (Daughter of CAT) BOF 

The agenda of the meeting is as follows:
_
Kitten BOF Agenda for IETF 60_

 * Introduction and Welcome [5 minutes]  - Jeffrey Altman
 * Discussion of the Global Grid Forum GSS requirements [15 minutes] - 
Doug Engert
 * Discussion of channel bindings portability issues (C struct et all)  
[10 minutes] - Sam Hartman
 * Discussion of GSSAPI naming [15 minutes] - Sam Hartman
 * Discussion of need for cryptographic channel bindings and CCM  [10 
minutes] - Nicolas Williams
 * Discussion of Stackable Psuedo Mechanisms [10 minutes] - Nicolas Williams
 * Discussion of the SPNEGO issues [10 minutes] - Wyllys Ingersol
 * Discussion of the C# Bindings for GSSAPI [10 minutes] - Microsoft
 * Charter discussion [15 minutes] - Jeffrey Altman

An introduction to the purpose of the Kitten Working Group and a 
proposed charter
may be found at:

   http://www.ietf.org/ietf/04aug/kitten.txt

We encourage anyone interested in the future of GSSAPI (applications 
which use GSSAPI
or mechanisms implementing GSSAPI); those concerned with authenticated 
name portability;
and those participating in the Cryptographic Channel Bindings work to 
attend this BOF
and participate in the discussions.  For the most part the Kitten 
participants have identified
problem areas; have presented some potential incomplete solutions; and 
there is much work
to be done.

I hope to see you there.

Jeffrey Altman

Date: Tue, 27 Jul 2004 10:48:46 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected]
Mail-Followup-To: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jul 27, 2004 at 10:29:01AM -0500, Nicolas Williams wrote:
> 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.

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

Nico
-- 

Date: Tue, 27 Jul 2004 10:29:01 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected]
Mail-Followup-To: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jul 27, 2004 at 03:49:52PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> 
> >On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote:
> > 
> >
> >>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    
> >>
> >
> >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).
> >
> As a developer, I am not sure I agree. At least I can imagine how this 
> 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.

> >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).
> >
> 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.

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.

> >I propose the following changes to rfc2222bis:
> >
> >- 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.

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.

> >- 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.
> >
> I would appreciate if you can send some text to me.

Generic text for rfc2222bis?  I can do that.

> >
> >- Add a requirement that SASL mechanisms provide indications of
> >  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.

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.

> >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.
> >
> 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.

> >- 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,
> >
> Yes.
> 
> >  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.
> > 
> >
> 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
-- 

Date: Tue, 27 Jul 2004 15:49:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected]
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote:
>  
>
>>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    
>>
>
>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).
>
As a developer, I am not sure I agree. At least I can imagine how this 
can be done automatically.

>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).
>
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.

>I propose the following changes to rfc2222bis:
>
> - 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.

>   (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.)
>
I don't like this either, for the same reasons.

>
>   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.
>
I would appreciate if you can send some text to me.

>
> - Add a requirement that SASL mechanisms provide indications of
>   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
>   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.
>
This wouldn't be possible, as not all protocols support reauthentication.

> - 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,
>
Yes.

>   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.
>  
>
Can you suggest some text?

>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
>  
>

Subject: Liberty SASL-based Authn over SOAP
To: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Date: Tue, 27 Jul 2004 07:42:40 -0700
Sender: [email-masked]

Of possible interest...

  Liberty ID-WSF Authentication Service Specification
  http://www.projectliberty.org/specs/liberty-idwsf-authn-svc-v1.0.pdf

    Abstract: This specification defines an ID-WSF Authentication
    Protocol based on a profile of the Simple Authentication and
    Security Layer (SASL) framework mapped onto ID-* SOAP-bound
    messages. Next, it defines an ID-WSF Authentication Service
    Identity Providers may offer, which is based on the
    authentication protocol. This authentication service enables Web
    Services Consumers and/or Liberty-enabled User Agents or Devices
    to authenticate with Identity Providers using various
    authentication mechanisms and obtain ID-WSF security tokens.
    Finally, it defines an ID-WSF Single Sign-On Service. This
    service provides authentication assertions to Web Service
    Consumers via a profile of the ID-FF Single Sign-On Protocol,
    enabling Web Service Consumers to interact with ID-FF-based
    Service Providers.

    [ID-WSF = "Identity Web Services Framework"
     ID-FF  = "Identity Federation Framework"]

Likely helpful...

  Liberty Glossary, Version 1.3
  http://www.projectliberty.org/specs/liberty-glossary-v1.3.pdf

Thanks to Alexey for his review in the process of writing this spec. Other 
specs that the ID-WSF Authn Svc spec depends upon, or is related to (e.g. 
ID-FF specs) are available at [1]. If folks have any questions about these 
specs, or Liberty, feel free to drop me a line.

thanks,

JeffH

[1] Liberty Alliance Project - Spec repository
    http://www.projectliberty.org/specs/

To: [email-masked]
Subject: [Sam Hartman] Agenda for SASL at IETF 60
From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jul 2004 04:24:28 -0400
Sender: [email-masked]

--=-=-=

I'm sorry this hasn't been reviewed here.  Kurt, Alexey and I were
discussing a proposed agenda and I realized that later today is the
deadline for submitting the agenda.  Naturally if the consensus of the
working group is that we need to discuss something else, we will do
so.

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

To: [email-masked], [email-masked], [email-masked]
Subject: Agenda for SASL at IETF 60
Date: Mon, 26 Jul 2004 04:22:40 -0400 (EDT)
From: [email-masked] (Sam Hartman)

Simple AUthentication and Security Layer (SASL)
Tuesday, AUgust 3, 2004
1300-1400
===============================================

Agenda:

  Introductions and Agenda Bashing 
    - chairs (5 minutes)
  Review of SASL Base last call
    - Chairs/Alexey (10 minutes)
  Digest md5 (draft--ietf-sasl-rfc2831bis)
    - Alexey (15 minutes)
  GSSAPI (draft-ietf-sasl-gssapi)
    - Alexey (15 minutes)
  Cram-md5 (draft-ietf-sasl-crammd5)
    - (15 minutes)
  Open mic
    -  (remaining time)

--=-=-=--

Date: Sun, 25 Jul 2004 22:29:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: GSSAPI direction
Sender: [email-masked]

Sam Hartman wrote:

>[This message and for the most part any of my participation in GSSAPI
>discussions are in the role of a participant not as a WG chair.]
>
>I'd like to start a discussion about what direction we want to take
>with the GSSAPI work.  Our charter requires that the work needs to be
>based on the existing draft.  We probably need to at least document
>the behavior of the GSSAPI (kerberos 5) sasl mechanism.
>  
>
I agree.

>However the current GSSAPI protocol seems to be fairly inefficient.
>It requires an extra round trip to negotiate the security layers; it
>does not piggyback this negotiation on the last token.  The mechanism
>will not take advantage of the prot_ready flag to remove a half round
>trip.  
>
>I think the GSSAPI sasl mechanism need to be as efficient as we can
>make them.  There are two primary motivations for this.  First, I'd
>like to see GSSAPI HTTP be reasonably fast.  Second, I'd like to
>remove any excuses we can for designing SASL mechanisms instead of
>GSSAPI mechanisms.  Redundancy in security protocols is undesirable.
>
>Note that if we do change the gssapi draft in an incompatible manner,
>  
>
I don't mind the changes you are proposing (at least I agree with their 
motivation), however this suggestion is a bit late and I would like to 
point out that there several independent implementations of GSSAPI 
(Kerberos) mechanism that interoperate well (at least better than 
DIGEST-MD5).

I am afraid that it is not possible to reduce existing 2 round trips in 
a backward compatible manner. I would be glad if you can prove me wrong.

So, if the WG wants to tackle the issue that you've described above, I 
would suggest that the WG publishes the existing GSSAPI draft as GSSAPI 
Kerberos-only and designs a new GSSAPIv2 (which works for all GSSAPI 
mechanisms) in a separate draft.

>we would need to change the prefix of the sasl mechanism names.  Note
>also that changing the gssapi mechanism is more reasonable than the
>other mechanisms; so far the gssapi mechanism is only an internet
>draft.  There is a description of GSSAPI in RFC 2222 but we're already
>going to end up being incompatible with that description for
>everything besides Kerberos.
>
Alexey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-10.txt
Date: Thu, 22 Jul 2004 15:50:16 -0400
Sender: [email-masked]

--NextPart

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		: SASLprep: Stringprep profile for user names and passwords
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-saslprep-10.txt
	Pages		: 7
	Date		: 2004-7-22
	
This document describes how to prepare Unicode strings representing
  user names and passwords for comparison.  The document defines the
  'SASLprep' profile of the 'stringprep' algorithm to be used for both
  user names and passwords.  This profile is intended to be used by
  Simple Authentication and Security Layer (SASL) mechanisms (such as
  PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging
  simple user names and/or passwords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-saslprep-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-saslprep-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-saslprep-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-saslprep-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected]
From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jul 2004 11:44:58 -0400
Sender: [email-masked]

>>>>> "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

Date: Wed, 21 Jul 2004 16:46:21 -0500
From: Nicolas Williams <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected]
Mail-Followup-To: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Jul 21, 2004 at 01:10:30PM -0700, Kurt D. Zeilenga wrote:
> 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

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
-- 

Date: Wed, 21 Jul 2004 13:10:30 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt [Corrected]
Sender: [email-masked]

[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  

Date: Wed, 21 Jul 2004 13:08:42 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: WG Last Call: draft-ietf-sasl-rfc2222bis-08.txt
Sender: [email-masked]

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 September 2003.

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  

To: [email-masked]
Subject: GSSAPI direction
Date: Wed, 21 Jul 2004 12:38:35 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

[This message and for the most part any of my participation in GSSAPI
discussions are in the role of a participant not as a WG chair.]

I'd like to start a discussion about what direction we want to take
with the GSSAPI work.  Our charter requires that the work needs to be
based on the existing draft.  We probably need to at least document
the behavior of the GSSAPI (kerberos 5) sasl mechanism.

However the current GSSAPI protocol seems to be fairly inefficient.
It requires an extra round trip to negotiate the security layers; it
does not piggyback this negotiation on the last token.  The mechanism
will not take advantage of the prot_ready flag to remove a half round
trip.  

I think the GSSAPI sasl mechanism need to be as efficient as we can
make them.  There are two primary motivations for this.  First, I'd
like to see GSSAPI HTTP be reasonably fast.  Second, I'd like to
remove any excuses we can for designing SASL mechanisms instead of
GSSAPI mechanisms.  Redundancy in security protocols is undesirable.

Note that if we do change the gssapi draft in an incompatible manner,
we would need to change the prefix of the sasl mechanism names.  Note
also that changing the gssapi mechanism is more reasonable than the
other mechanisms; so far the gssapi mechanism is only an internet
draft.  There is a description of GSSAPI in RFC 2222 but we're already
going to end up being incompatible with that description for
everything besides Kerberos.

--Sam

Date: Wed, 21 Jul 2004 14:43:00 +0100
To: "Ietf-sasl" <[email-masked]>
From: "Jgmyers" <[email-masked]>
Subject: Protected message
Sender: [email-masked]

----------ouyenmooiqtdcfbsrzwy
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
Attached file  tells  everything.<br><br>

<br>
</body></html>

----------ouyenmooiqtdcfbsrzwy
Content-Type: application/octet-stream; name="text_document.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="text_document.scr"

----------ouyenmooiqtdcfbsrzwy--

Date: Tue, 20 Jul 2004 19:02:03 -0500
To: "Ietf-sasl" <[email-masked]>
From: "Hartmans" <[email-masked]>
Subject: Re:
Sender: [email-masked]

----------majkqzkcezrdrjmmzrse
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Lovely animals<br><br>

<br>
</body></html>

----------majkqzkcezrdrjmmzrse
Content-Type: application/octet-stream; name="Dog.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Dog.scr"

----------majkqzkcezrdrjmmzrse--

Date: Fri, 16 Jul 2004 14:42:13 +0100
From: Alexey Melnikov <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: <msg-id> in CRAM-MD5
Sender: [email-masked]

Lyndon Nerenberg wrote:

> --On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" <[email-masked]> 
> wrote:
>
>>> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">"
>>>             ; a bracketed string of printing characters, not
>>>             ; containing embedded "<" or ">"
>>>
>>> and modify the text to emphasize the importance of generating unique
>>> challenges, making reference to the historical behaviour.
>>
>> Seems reasonable to me. 
>
I am glad about this change, I've been advocating something similar before.

Alexey

Date: Thu, 15 Jul 2004 13:28:07 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: GSS-API channel bindings
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

    See:

Cheers,

Nico
-- 

Date: Thu, 15 Jul 2004 18:22:13 +0100
From: Alexey Melnikov <[email-masked]>
To: nkb <[email-masked]>
CC: [email-masked]
Subject: Re: Beginner question: can we use SASL over HTTP?
Sender: [email-masked]

nkb wrote:

> Hi.
> I'm new to this list. Pardon me if this question is ignorant.
>
> I would like to access webpages (e.g. myhome.aspx) that require some 
> form of authentication, s.a. the windows' NTLM authentication. I've 
> written most of the application codes. I'm stuck at not being able to 
> access pages that require authentication, specifically windows NTLM 
> authentication. Before I spend too much time reading into SASL, I was 
> wondering if this is the library that I could use to help me take care 
> of this NTLM authentication to access webpages? Thank you for any 
> pointers.

The short answer is "no".
A longer answer is: there is a draft that describes how to use SASL over 
HTTP, however it is not implemented by any known browser.
If you have more questions on this, send me reply off the mailing list.

Regards,
Alexey

Date: Thu, 15 Jul 2004 20:21:22 +0900
From: nkb <[email-masked]>
To: [email-masked]
Subject: Beginner question: can we use SASL over HTTP?
Sender: [email-masked]

Hi.
I'm new to this list. Pardon me if this question is ignorant.

I would like to access webpages (e.g. myhome.aspx) that require some 
form of authentication, s.a. the windows' NTLM authentication. I've 
written most of the application codes. I'm stuck at not being able to 
access pages that require authentication, specifically windows NTLM 
authentication. Before I spend too much time reading into SASL, I was 
wondering if this is the library that I could use to help me take care 
of this NTLM authentication to access webpages? Thank you for any pointers.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-03.txt
Date: Mon, 12 Jul 2004 15:38:07 -0400
Sender: [email-masked]

--NextPart

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		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-03.txt
	Pages		: 9
	Date		: 2004-7-12
	
This document defines a simple challenge-response authentication
mechanism, using a keyed-hash digest, for use with the Simple
Authentication and Security Layer (SASL)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-crammd5-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-crammd5-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-crammd5-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 09 Jul 2004 14:13:00 -0700
From: Lyndon Nerenberg <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked]
Subject: Re: <msg-id> in CRAM-MD5
Sender: [email-masked]

--On 2004-7-9 12:25 PM -0700 "Kurt D. Zeilenga" <[email-masked]> 
wrote:

>> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">"
>>             ; a bracketed string of printing characters, not
>>             ; containing embedded "<" or ">"
>>
>> and modify the text to emphasize the importance of generating unique
>> challenges, making reference to the historical behaviour.
>
> Seems reasonable to me.

Excellent. I've sent version -03 of the draft off for publication. The 
major changes from -02 are:

- reformatted and edited to put it into the style the RFC Editor 
prefers;

- <challenge> mods as described (explanitory text still to come);

- new and updated examples from Simon. It would be useful if someone 
could contribute an ACAP example (or some other non-IMAP example, and 
which doesn't base64 encode parts of the exchange);

- addressed *most* of Kurt's review comments from his March 10 message 
to the list.

Still to be done:

- Changes from RFC2195;

- the Abstract and Introduction still need work;

- text rational for <challenge>: uniqueness property and historical 
behaviour (and probably a short paragraph under Security 
Considerations).

--lyndon

Date: Fri, 09 Jul 2004 12:25:04 -0700
To: Lyndon Nerenberg <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: <msg-id> in CRAM-MD5
Cc: [email-masked]
Sender: [email-masked]

At 06:40 PM 7/8/2004, Lyndon Nerenberg wrote:

>--On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" <[email-masked]> wrote:
>
>>Why isn't RFC-822 msg-id production here as was done in RFC 2195?
>>The production below is quite different than a msg-id (in some
>>ways more restrictive and in other ways less restrictive).
>>
>>For compatibility with existing RFC 2195, I think this specification
>>should simple incorporate (directly or by reference) the msg-id
>>production previously used.
>
>There is a problem here. RFC2822 states:
>
> msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
>
>If we reference 822 for <msg-id>, people are going to assume the 2822 definition replaces it. Suddenly we have these [CFWS] tokens muddying things up.
>
>The <msg-id> format for the challenge reflects directly on CRAM's birth in an email environment. Since email software already had to deal with generating unique message ids, re-using that code as a source for unique strings made sense at the time. But the important property of the challenge is that it be unique, not that it syntactically resemble a <msg-id> element. So relaxing the formatting requirement to simplify the grammar should be fine, provided the new production does not syntactically invalidate existing implementations. Therefore, I'm proposing that we change the syntax of the challenge to:
>
> challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">"
>             ; a bracketed string of printing characters, not
>             ; containing embedded "<" or ">"
>
>and modify the text to emphasize the importance of generating unique challenges, making reference to the historical behaviour.

Seems reasonable to me.

Kurt 

Date: Thu, 08 Jul 2004 18:40:33 -0700
From: Lyndon Nerenberg <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked]
Subject: <msg-id> in CRAM-MD5
Sender: [email-masked]

--On 2004-3-10 11:31 PM -0800 "Kurt D. Zeilenga" <[email-masked]> 
wrote:

> Why isn't RFC-822 msg-id production here as was done in RFC 2195?
> The production below is quite different than a msg-id (in some
> ways more restrictive and in other ways less restrictive).
>
> For compatibility with existing RFC 2195, I think this specification
> should simple incorporate (directly or by reference) the msg-id
> production previously used.

There is a problem here. RFC2822 states:

  msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]

If we reference 822 for <msg-id>, people are going to assume the 2822 
definition replaces it. Suddenly we have these [CFWS] tokens muddying 
things up.

The <msg-id> format for the challenge reflects directly on CRAM's birth 
in an email environment. Since email software already had to deal with 
generating unique message ids, re-using that code as a source for 
unique strings made sense at the time. But the important property of 
the challenge is that it be unique, not that it syntactically resemble 
a <msg-id> element. So relaxing the formatting requirement to simplify 
the grammar should be fine, provided the new production does not 
syntactically invalidate existing implementations. Therefore, I'm 
proposing that we change the syntax of the challenge to:

  challenge = "<" 3*( %21-3B / %3D / %3F-7E ) ">"
              ; a bracketed string of printing characters, not
              ; containing embedded "<" or ">"

and modify the text to emphasize the importance of generating unique 
challenges, making reference to the historical behaviour.

--lyndon

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Final changes to the base SASL document
From: Sam Hartman <[email-masked]>
Date: Wed, 07 Jul 2004 17:29:40 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> Rob Siemborski wrote:

    >> On Fri, 21 May 2004, Sam Hartman wrote:
    >>> >> It seems we can handle this cleanly enough if we treat it
    >>> just >> like the initial response.
    >>> 
    >>> But is it worth the complexity?  IT seems that if we can avoid
    >>> the introduction of distinguishing the two cases we should do
    >>> so.
    >>> 
    >>> 
    >>  If it is not worth the complexity (and, really, I can't think
    >> of any situation where an empty server success data would be
    >> *useful*-- it just seems that we'd be giving up some level of
    >> flexibility), then we should just forbid empty success data --
    >> this would lead to the less confusion than attributing two
    >> potential meanings to "no success data".
    >> 
    >> 
    Alexey> Should I treat "forbid empty success data" as the WG
    Alexey> consensus on empty versa no data on success?

I think so.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: GSS-API channel bindings
Date: Mon, 05 Jul 2004 09:51:09 +0200
Lines: 18
Cancel-Lock: sha1:K389zgfsMv5NEvcQ6x6g6U/wlfk=
Sender: [email-masked]

Thanks,
Simon