Subject: Agenda items to discuss

From: [email-masked] (Sam Hartman)
Date: Wed, 29 Oct 2003 13:44:05 -0500 (EST)

There has been a lot of discussion on the list since the last IETF and
I'm curious which issues actually need meeting time.  I'd appreciate
it if people could suggest issues that still seem to be open.

Thing I think may be open or need discussion are:

* Initial server challenges especially as they interact with SMTP
* Security layer replacement in the base SASL spec
* Authorization ID text (data vs blob, confusion about restriction, etc)
* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want
to develop guidance for protocol designers on this issue?

I think most of the other changes that have been brought forward have
been resolved; please correct me if I'm wrong.  I think Greg's
comments on implementing SASL have not suggested any specific changes
to documents that need discussion.

There's also been a lot of IDN related discussion in the Kerberos
working group.  So far, I don't think any of that discussion affects
saslprep.  If any of those issues do end up affecting saslprep, we may
at least want to be aware of them.  I'll review those discussion
within the next week.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 29 Oct 2003 16:51:41 -0500

> to develop guidance for protocol designers on this issue?

I won't be at the meeting, but I'd like to weigh in with the opinion
that we shouldn't make it any harder for implementations to do dual
encryption of data for defense-in-depth.  It may seem redundant and
expensive to encrypt or sign twice (and it's certainly fair for an
implementation to avoid using a security layer if it's running over
TLS), but it's not completely redundant; the keys used for one security
layer may be compromisable under different assumptions than the keys
used for another.

For example: I make a TLS connection to an MIT server and then
SASL-authenticate via GSSAPI.  Unbeknownst to me, a CA trusted by my
client has issued a bogus X.509 certificate for MIT to an attacker.  The
attacker intercepts my connection, initiates its own connection to the
real MIT server, and passes through my communications so that GSSAPI
authentication succeeds.  If my client insists on using a SASL security
layer, the attacker will not be able to modify (or perhaps even read) my
communications despite having compromised TLS.

I'm not sure if anyone was seriously considering disallowing dual
security layers, but RFC 3080 section 4.1 does so, so it seemed worth
heading off.

> to documents that need discussion.

Correct; I hope my comments will be kept in mind for future work, but
they don't have any ramifications for current documents.

(And, apologies for the misconception about authzids.  I still feel they
should have appeared within the framework and not within mechanisms, but
I was wrong to assume that they were specific to DIGEST-MD5.)

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Oct 2003 14:51:09 -0800

> to develop guidance for protocol designers on this issue?

I think this should be discussed.

I think the guidance we want to give is: don't delegate session
protection from one layer to another without confirming that the
end-points at both layers are the same.

See:

http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt

It would be nice if SASL had a channel bindings facility.  Such a
facility could be added or applications could be encouraged to exchange
channel bindings data integrity protected at the SASL layer.

Can GSS-API channel bindings facility be used when using the GSS-* SASL
mechanisms?

Cheers,

Nico
--

---

From: "Jeffrey Altman [Kermit Project Volunteer]" <[email-masked]>
Date: Wed, 29 Oct 2003 18:44:26 -0500

>Can GSS-API channel bindings facility be used when using the GSS-* SASL
I second this sentiment.  We need to provide advice on how the 
underlying session security can be validated as part of the SASL 
authentication OR after the authentication by exchanging messages using 
the SASL Security Layer which can be then be turned off if validation 
was successful.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Oct 2003 15:44:12 -0800

On Wed, Oct 29, 2003 at 06:44:26PM -0500, Jeffrey Altman [Kermit Project Volunteer] wrote:
> [...]
> [...]

> the SASL Security Layer which can be then be turned off if validation 

Note that I did post a request for this and other WGs to review the
channel bindings draft.  There is a section in that I-D about SASL, BTW.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 11:45:55 -0500

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

    Nicolas> On Wed, Oct 29, 2003 at 01:44:05PM -0500, Sam Hartman
    Nicolas> wrote:
    >> * There was some discussion of multiple layers of encryption
    >> (TLS vs security layers) in XMPP; do we want to develop
    >> guidance for protocol designers on this issue?

    Nicolas> I think this should be discussed.

    Nicolas> I think the guidance we want to give is: don't delegate
    Nicolas> session protection from one layer to another without
    Nicolas> confirming that the end-points at both layers are the
    Nicolas> same.

This approach is out of scope for the SASL working group as it cannot
be implemented within the current charter.  If you want to discuss the
approach on the list, that's fine.  However I don't think modifying
SASL to gain channel bindings is appropriate for meeting time at the
IETF.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Oct 2003 09:44:53 -0800

>     Nicolas> confirming that the end-points at both layers are the
Sam> This approach is out of scope for the SASL working group as it
Sam> cannot be implemented within the current charter.  If you want to
Sam> discuss the approach on the list, that's fine.  However I don't
Sam> think modifying SASL to gain channel bindings is appropriate for
Sam> meeting time at the IETF.

I don't see how the text from me that you quote could possibly be out of
scope for this WG - that text calls for "guidance" - security
considerations text.

The following text from me which you didn't quote does propose two
things, one of which may well be out of scope for the WG - which is fine
by me, as long as guidance is given:

Nico> It would be nice if SASL had a channel bindings facility.  Such a
Nico> facility could be added or applications could be encouraged to
Nico> exchange channel bindings data integrity protected at the SASL
Nico> layer.

I can see that adding a channel bindings facility to SASL may be out of
scope for this WG.

That said, you could argue that the channel bindings I-D itself
provides, or should provide, sufficient guidance for developers of SASL
application protocols.  If so, please review the text in section 3.2 of
draft-ietf-nfsv4-channel-bindings-00.txt.

Thanks,

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Wed, 29 Oct 2003 16:51:41 -0500

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Oct 2003 14:51:09 -0800

See:

Cheers,

Nico
--

---

From: "Jeffrey Altman [Kermit Project Volunteer]" <[email-masked]>
Date: Wed, 29 Oct 2003 18:44:26 -0500

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Oct 2003 15:44:12 -0800

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 11:45:55 -0500

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Oct 2003 09:44:53 -0800

Thanks,

Nico
--