Subject: IETF 53 SASL bar BoF minutes

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sun, 24 Mar 2002 23:54:50 -0800 (PST)

Respectfully submitted,

 - RL "Bob"

---

SASL bar BoF at IETF 53, 2002-03-18

Some SASL-interested folks met, yes, in the entirely too smoky back of
the bar at the Minneapolis Hilton.  Attendees included at least:
Alexei Melnikov, Kurt Zeilenga, John Myers, Larry Greenfield, Chris
Newman, Marshall Rose (who graciously paid for the drinks), RL "Bob"
Morgan, Walter Wong, and several others whose names I didn't get.
Here are some notes.  I apologize for any issue-mangling.

John will send the latest in-process draft revision of
draft-myers-saslrev to the list, in glorious nroff (done).  This will
update saslrev-01 when it's ready.

There was discussion of the buffer size issue.  Some application
protocols limit how much data can be sent in an application PDU, eg
NNTP and SMTP.  This is a problem if a security mechanism needs to
send more data than this in its message.  One approach is to say that
app profiles need to specify methods to send unlimited amounts of
data, but this opens up implementations to DoS attacks.  So a
"minimax" number needs to be picked: application profiles need to be
able to send at least N bytes, and mechanisms need to be able to work
while sending at most N bytes (or potentially fail with some compliant
app implementations).  A number of 4K was proposed, but this could
easily be too low if a security mechanism sends certificates, as some
do.  The group settled on 64K as being reasonable for this.  This
means 64K of decoded data, hence potentially more on the wire if, say,
base64 encoding is used.  In any case wording should be added to warn
implementors about potential DoS attacks.

The other main issues are about the authorization identifier.  The
saslrev doc specifies default handling of the authzid, so an
application profile only has to say something about it if it wants to
modify this default (but it can do this if needed).  It also specifies
the use of ISO 10646 and Unicode normalization form KC for authzids.
Question:  can an app profile (eg SACRED) mandate a null authzid?
Sure, though perhaps short-sighted.  Question:  can an app profile
say that authzid is, or can be, ignored?  No, not a good idea, if
authzid is present it has to be used for authorization, or the
authentication is rejected.

draft-josefsson-base-encoding-03 specifies a BASE32 that is different
from the BASE32 used in the GSSAPI draft for encoding mechanism OIDs,
so it will be proposed to change the SASL-GSSAPI doc to use the
josefsson-specified version.  May be a compatibility issue if anyone
has implemented to that draft.  Also the josefsson doc is too liberal
in accepting non-alphabet chars in input string; should say "reject
unless app profile specifically permits".

The Digest-MD5 SASL mechanism doc:  Chris Newman will either finish it
soon or hand it off to someone else who will.

ANONYMOUS and PLAIN mechanisms:  Kurt will do them both in one
document.  PLAIN will specify "must only use with appropriate data
protection", eg TLS.  EXTERNAL will stay in the base SASL document.
Note that the LDAP authmeth document shouldn't deprecate the use of
PLAIN.

There was discussion of sequence of START-TLS vs SASL AUTH.  Different
protocols do this differently (LDAP permits whatever, BEEP says TLS
comes first), so probably nothing to say in base doc.  Of course
specs also don't say much about TLS transitions in mid-stream.

Still need a Working Group?  Doesn't seem like it.  Need a T-shirt:
"SASL: WG free since 1997".  API doc should be Informational when it's
done.  It seems reasonable to complete the above core docs in the next
few weeks, have a "BoF last call" (or mailing-list last call), then
send to IESG.  (But, at SAAG, Jeff Schiller said the WG will be
started after all ...)

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 10:11:38 -0800

>implementors about potential DoS attacks.

I'm a bit out of date on SASL at the moment, but I do want to make a 
general comment. Over the last few years I've worked on HTTP, POP, and SMTP 
for PalmOS and for lower end CDMA handsets. In particular I've got these 
protocols running with SSL. These environments don't have much heap RAM, in 
particular the old PalmOS devices and the low end CDMA devices. Usually the 
RAM is less than 70Kb.

Most of these protocols can be implemented with very little RAM. Our SMTP 
client for example uses on the order of 3Kb. The major exception is SSL 
which requires a 16Kb buffer so a record can be accumulated and it's 
integrity hash checked. There's not really any way around this. You just 
have to have a 16Kb buffer.

So, if the length we're dealing with here in SASL is for a record over 
which a signature or hash is computed then I'd object to 64Kb on the 
grounds that it will be difficult to implement on small low end devices. It 
will cause problems that almost no other internet protocol causes for these 
handsets. 16Kb is big, but manageable and already a requirement for SSL.

To be completely specific, I'm worried about handset that have Qualcomm's 
Brew API in them. Most of Brew is based on open Internet standards (no 
WAP). We've got lots of applications and protocols running on devices that 
have on the order of 70Kb of RAM available. Brew is targeted to run on low 
end (less than $100) handsets, these have less RAM because costs is reduced 
by having smaller memory parts. I expect there's similar issues for GSM and 
wireless phone application environments.

LL