Subject: [sasl] MOGGIES Proposed Charter

From: Shawn Emery <[email-masked]>
Date: Mon, 17 May 2010 23:12:33 -0600

As discussed; attached is the proposed charter text for a new working 
group (MOGGIES) based on future direction in the GSS-API and SASL 
space.  Please provide any feed-back to the lists by the end of May.

Thank you,

Shawn Emery and Tom Yu (co-chairs)
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 May 2010 07:51:04 +0200

The charter looks fine to me.  Do we have energy to also look at moving
RFC 4422 from Proposed to Draft?  Unless I'm missing something, that
shouldn't be too complicated.  I recall some implementation evaluation
has already started.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 May 2010 17:20:03 +0100

>shouldn't be too complicated.  I recall some implementation evaluation
I wouldn't object to this, as long as I don't need to write the implementation report. I can contribute necessary information for the Cyrus SASL though.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 May 2010 18:27:14 +0100

> space.  Please provide any feed-back to the lists by the end of May.

Thanks for writing a proposal.

> Shawn Emery and Tom Yu (co-chairs)

-------------------------------------------------

>MOGGIES (Mechanisms Of Generating Generically Interoperable & Effective
>Security)
>
>
>Description of Working Group:
>
>The Generic Security Services (GSS) API and Simple Authentication and Security
>Layer (SASL) provide various applications with a security framework for secure
>network communication.  The purpose of the Mechanisms Of Generating Generically
>Interoperable & Effective Security (MOGGIES) working group (WG) is to develop
>extensions/improvements to the GSS-API, shepherd specific GSS-API security
>mechanisms, revise SASLprep with a stringprep profile from the NewPrep WG,
>
I think that SASLPrep should be done in the proposed newprep WG. There 
might be some bits that might be done in MOGGIES, but at this point I am 
not convinced there are any.

I am Ok with the rest of your list.

>and provide guidance for any new SASL-related submissions.
> 
>This working is chartered to specify the following extensions and improvements
>(draft-yu-kitten-api-wishlist-00) to the GSS-API:
>
>* Provide new interfaces for credential management, which include the following:
>	initializing credentials
>	iterating credentials
>	exporting/importing credentials
>
>* Specify interface for asynchronous calls.
>
>* Define interfaces for better error message reporting.
>
>* Specify an interface for reporting the security strength of GSS-API mechanism.
>
>* Provide a more programmer friendly interface for application developers.
>
>This working group is also chartered to transition proposed SASL mechanisms as
>GSS-API mechanisms:
>  
>
What does this mean? Do you mean that they become GS2 mechanisms?

>* A SASL Mechanism for OpenID
>	draft-lear-ietf-sasl-openid-00
>* A SASL Mechanism for SAML
>	draft-wierenga-ietf-sasl-saml-00
>
>The transition from SASL to GSS-API mechanisms will allow a greater set of
>applications to utilize said mechanisms with SASL implementations that support
>the use of GSS-API mechanisms in SASL (RFC 5801).
>
RFC 5801 hasn't been published yet. So I don't think we should reference it.

>The working group shall also revise SASLprep with a stringprep profile developed
>by the NewPrep WG.
>  
>
See above.

>This working group will review SASL related submissions as well, including any
>new SASL mechanisms proposed.
>
IMHO, this is a bit open ended for IESG.
Should we restrict this to SASL mechanisms, or are we saying that 
updates to SASL protocol profiles are also in scope? I think the answer 
is probably "no", although they should be reviewed here.

On a somewhat related note: is there still any interest in publish 
"DIGEST-MD5-to-historic" document, or should I request its publication 
outside of a Sec Area WG?

>Deliverables:
>
>* GSS-API: initializing credentials
>[editor: TBD]
>
>* GSS-API: iterating credentials
>[editor: TBD]
>
>* GSS-API: exporting/importing credentials
>[editor: TBD]
>
>* GSS-API: specification for asynchronous calls
>[editor: TBD]
>
>* GSS-API: interfaces/improvements for better error message reporting
>[editor: TBD]
>
>* GSS-API: reporting security strength
>[editor: TBD]
>
>* GSS-API: programmer friendly interfaces
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for OpenID
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for SAML
>[editor: TBD]
>
>* SASL: Revise SASLprep with stringprep from the NewPrep WG
>[editor: TBD]
>
>
>Goals and Milestones:
>
>July 2010	First Meeting
>
>TBD		Listed Work Items
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 May 2010 19:47:13 +0200

Alexey Melnikov <[email-masked]> writes:

> I wouldn't object to this, as long as I don't need to write the
> implementation report. I can contribute necessary information for the
> Cyrus SASL though.

I now recall one issue that was causing trouble earlier: SASLprep.  It
wasn't clear (at least not to me) whether it is a good idea to move RFC
4422 to Draft as long as it referenced SASLprep.  Now, the references to
SASLprep only affect other specifications, not implementations, thus we
might be able to dodge this issue completely by explaining that.

On the other hand, perhaps we should punt on moving SASL to Draft
Standard until we have some clear vision for the future of i18n in SASL.
The SASLprep replacement work the WG likely will be chartered to take on
may result in an update to RFC 4422, and we could move that replacement
document to Draft Standard instead of RFC 4422.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 May 2010 18:48:41 +0100

>document to Draft Standard instead of RFC 4422.
Good point.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 May 2010 20:02:26 +0200

> outside of a Sec Area WG?

I'd like to see publishing this in the charter.  We shouldn't let people
use DIGEST-MD5 without a big warning, and I believe we can establish WG
consensus around that.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 May 2010 14:15:22 -0500

On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
> As discussed; attached is the proposed charter text for a new
> working group (MOGGIES) based on future direction in the GSS-API and
> SASL space.  Please provide any feed-back to the lists by the end of
> May.

I don't love the name (I keep thinking "MOOGIES", which sounds like
something gross :), but I'll live; I have no better suggestions.

> * Specify an interface for reporting the security strength of GSS-API mechanism.

I'd word that differently:

 * Specify an interface for enforcing security strength of GSS-API mechanisms.

The reason is that "reporting the security strength" of something
implies [to me] an absolute measure of security strength, and I don't
think it's possible to degisn a good, _stable_, absolute measure of
security strength.

> new SASL mechanisms proposed.

New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close the
WG (and even SASL) to new non-GS2 mechanisms?  Might there be conflicts
with EMU?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 17:09:17 -0400

> something gross :), but I'll live; I have no better suggestions.

I don't even _understand_ the name.  Or the expansion.
Can't we have something that doesn't make me (and anyone not already 
familiar with what we're working on) go "Huh?" ?

>> This working group will review SASL related submissions as well,
>> including any new SASL mechanisms proposed.
>

This WG should review proposals for new SASL and GSS-API mechanisms, and 
such work should be considered to fall within its general scope, but it 
should be constrained to actually work only on mechanisms specifically 
listed in the charter.  If we want to work on a new mechanism, we can amend 
the charter.

It should also be willing to provide advice and review on non-mechanism 
proposals such as defining use of SASL or GSS-API in a new or existing 
protocol.  However, actual work on such proposals should be done in the 
relevant WG for the protocol in question, and _not_ in the new one.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 May 2010 16:38:40 -0500

On Tue, May 18, 2010 at 05:09:17PM -0400, Jeffrey Hutzelman wrote:
> This WG should review proposals for new SASL and GSS-API mechanisms,
> and such work should be considered to fall within its general scope,
> but it should be constrained to actually work only on mechanisms
> specifically listed in the charter.  If we want to work on a new
> mechanism, we can amend the charter.

OK, which mechanisms, if any should the WG work on?

We have SCRAM, we have GS2, we have RFC4121, and KRB-WG will work on
IAKERB.  That leaves only PKU2U, and that'd be up to Larry.

> It should also be willing to provide advice and review on
> non-mechanism proposals such as defining use of SASL or GSS-API in a
> new or existing protocol.  However, actual work on such proposals
> should be done in the relevant WG for the protocol in question, and
> _not_ in the new one.

Indeed.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 May 2010 18:36:42 -0400

--On Tuesday, May 18, 2010 04:38:40 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > New SASL mechanisms?  Why not new GSS-API mechanisms?  Why not close
>> > the WG (and even SASL) to new non-GS2 mechanisms?  Might there be
>> > conflicts with EMU?
>>

The ones already in the proposed charter.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 May 2010 08:31:43 +0200

> familiar with what we're working on) go "Huh?" ?

+1

I would prefer something self-explanatory, like SASLGSS.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 May 2010 10:01:09 +0100

>> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote:
 [...]

> mechanism, we can amend the charter.

+1.

> should be done in the relevant WG for the protocol in question, and 

I think I was quite clear on this in my reply, but in case I wasn't: +1.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 May 2010 10:31:24 +0100

[...]

>WG (and even SASL) to new non-GS2 mechanisms?  Might there be conflicts
I don't think there is immediate overlap with EMU, although I think this 
needs a bit more investigation.

---

From: Andrew Bartlett <[email-masked]>
Date: Wed, 19 May 2010 16:42:03 +1000

> I would prefer something self-explanatory, like SASLGSS.

Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun.  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 May 2010 13:49:06 -0400

> Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun.

Again, huh?

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 May 2010 00:38:22 +0200 (MEST)

Nicolas Williams wrote:
> think it's possible to design a good, _stable_, absolute measure of
> security strength.

I think that the comparable strength measured in "Bits of security"
as used by NIST SP800-57 section 5.6.1 should be sufficiently stable.

What changes over time is the amount of "strength" that one considers
secure.  

      fairly stable           gradually fading
        Bits of           characterisation of strength
        security                 
          <40                 ridiculously weak
          40                  extremely weak
          56                  very weak
          64                  weak
          80                  mediocre
          96                  fair
          112                 good
          128                 strong
         >128                 very strong

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 May 2010 17:56:47 -0500

> as used by NIST SP800-57 section 5.6.1 should be sufficiently stable.

I don't.  I'd much rather be able to ask for a credential or context
that meets a given security profile, or to check what profiles a given
credential or context meets.  The profiles should be named

Possible profile names and semantics:

 - FIPS-140-x        -> obvious semantics (FIPS-140-x compliant cipher suites)
 - <other standards> -> obvious semantics
 - Strong            -> obvious-but-local semantics
 - Fast              -> obvious-but-local semantics
 - Interoperable     -> standard, per-mechanism semantics
 - Weak              -> standard, per-mechanism semantics (basically:
                        interoperable cipher suites + obsolete suites)

 - Local-*           -> locally-defined profile names and semantics

> What changes over time is the amount of "strength" that one considers

Not only.  Cryptanalysis progresses and the relative strengths of
various algorithms can vary.

I abhor anything remotely like a quantification of cryptographic
strength, and will for the forseeable future.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 May 2010 22:11:11 +0200 (MEST)

Simon Josefsson wrote:
> > >   [..."MOGGIES"...]

I had to look up the term MOGGIES in a dictionary.

The meaning of the expansion appears a little weird/non-intuitive to me.

> I would prefer something self-explanatory, like SASLGSS.

Do we need to rename Kitten at all?

How about "KittenS" ?

-Martin

---

From: Tom Yu <[email-masked]>
Date: Fri, 21 May 2010 18:43:35 -0400

> strength, and will for the forseeable future.

The meaning of "security strength" can be made fairly precise by
definitions involving, for example, the base 2 logarithm of the time
or space complexity of attacking an algorithm, e.g., NIST SP 800-57,
Part 1, Section 5.6.1.  That text gives the example of three-key
triple DES, which has 168 bits of key material and has 112 bits of
effective security strength.

Yes, this means that you may have to revise the numeric "security
strength" that you report for a given cryptographic association as new
cryptanalytic attacks are discovered, but you would have to do that
anyway with a non-numeric method of reporting "security strength".

As I understand it, defeating an algorithm with a security strength of
128 bits approaches or exceeds reasonable information-theoretic bounds
on the computational capacity of the universe, unless you consider
quantum computing to be a credible threat.  I expect that the amount
of "strength" that we consider secure is unlikely to change unless
tremendous advances occur in the realm of quantum computing.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 May 2010 18:09:00 -0500

> anyway with a non-numeric method of reporting "security strength".

Yes, but that way we get to also have policy names, both, standard and
locally-defined, as the interface _for users_.

Let me refine my problem with numeric measures of cryptographic strength
in APIs.  There are two.  First, what's better in a UI (I'm betting API
particulars will leak into UIs)?  Second, do we want to encourage users
and/or developers to make relative cipher suite strength comparisons?

Looking at it from a UI perspective I'd rather have UI-friendly security
strength indications than numeric ones.  One might argue that numeric
measures of strength are what users are used to, and there's no sense in
trying to change that.  Is anyone up for that argument?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 23 May 2010 23:36:55 -0500

On Sat, May 22, 2010 at 11:22:32AM +0200, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Let me refine my problem with numeric measures of cryptographic
> >strength in APIs. There are two. First, what's better in a UI (I'm
> >betting API particulars will leak into UIs)?
> 
> As (mostly former) UI-head: Numbers are better than magic constants.
> Magic constants have a way of getting into a fight with UI
> translation.
> 
> There are good ways to handle magic constants, but errare humanum
> est, programmers are human, and my impression is that magic
> constants are associated with more UI snafus than numbers.

These wouldn't be constants though -- that's part of the point.

> >Second, do we want to encourage users and/or developers to make
> >relative cipher suite strength comparisons?
> 
> Other than "Pick the best?"

One could certainly have locally defined preference orders for cipher
suites.  Numeric sorting by "strength number" needn't enter into it.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 22 May 2010 11:22:32 +0200

As (mostly former) UI-head: Numbers are better than magic constants. 
Magic constants have a way of getting into a fight with UI translation.

There are good ways to handle magic constants, but errare humanum est, 
programmers are human, and my impression is that magic constants are 
associated with more UI snafus than numbers.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 24 May 2010 08:34:38 +0200

> These wouldn't be constants though -- that's part of the point.

Aren't you talking about sendint something like "cipher suite foo is 
pretty strong"? "Pretty strong" is a magic constant.

> suites.  Numeric sorting by "strength number" needn't enter into it.

One could, but orthogonal to UI issues.

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 May 2010 10:36:26 -0500

> pretty strong"? "Pretty strong" is a magic constant.

No, not on the wire.  We're talking about the API, and the UI.

On the wire apps should negotiate mechanisms, and mechanisms should
negotiate ciphers.  (Yes, that's a two-layer negotiation, and that's
bad.  What we should do is negotiate both up front by having a mechanism
name (OID) for every cipher suite each mechanism supports.)

> One could, but orthogonal to UI issues.

Right, and therein lies one problem with strength numbers: we've no clue
how they'll be used, and quite possibly they'll be used inappropriately.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 24 May 2010 17:58:47 +0200

> No, not on the wire.  We're talking about the API, and the UI.

Same thing. A piece if information is sent from someone's domain to 
someone else's domain. Whether that involves network traffic is not very 
important; the most significant bit is that someone's code provides 
information to someone else's code, and the two "someone"s don't know 
each other.

> how they'll be used, and quite possibly they'll be used inappropriately.

That applies no matter how you package the piece of information.

I know one instance where they tried to get away from packaging the 
information as a piece: A Windows thing called TWAIN where the two 
pieces of code (which may or may not be linked into the same process) 
cooperate across the API to build a UI. TWAIN does get away from the 
packaging, but the result is not nirvana.

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 May 2010 11:41:34 -0500

On Mon, May 24, 2010 at 05:58:47PM +0200, Arnt Gulbrandsen wrote:
> someone else's domain. Whether that involves network traffic is not
> very important; the most significant bit is that someone's code
> provides information to someone else's code, and the two "someone"s
> don't know each other.

If some piece of information is not sent on the wire (neither explicitly
nor implicitly) then it's purely local.  The "two someone's", if there
are any, would be: standards-setting organizations, registries and
administrators on the one hand (these define policies and don't have to
coordinate with each other), and users (who might get to select policies
in some cases, or who might not get any choices but could still inquire
as to what policies are in effect).

In particular, the app developer is out of the loop with my approach,
which I think is a useful result.  There's no danger of having to mess
with cipher suites' "assigned" strength numbers to work around developer
mistakes, for example, if developers have only symbolic policy
references to play with.

> That applies no matter how you package the piece of information.

One can certainly provide _less_ information.  Using policy names
instead of absolute strength numbers does just that.

If you know that two cipher suites meet the [would-be standard]
'FIPS-140-2' policy but otherwise know nothing else then you don't know
which is stronger, therefore you can't sort them.  Now, you might have a
locally-defined policy that indicates a preference for one or ther
other, but it will be a locally-defined policy, subject to [fast, that
is, not requiring patching] change.

[Apologies for the length of the following.  I think it's useful.]

You might also be able to derive a preference order by combining
multiple policies.  For example, you might create a semi-ordered set of
cipher suites as follows:

    (set1 ^ set2) v set1 v set2

where set1 might be 'FIPS-140-2' and set2 might be 'Interoperable', and
where each successive set union orders additions to the resulting set as
following the members that were already in it.  If the intersection of
set1 and set2 has more than one element then these will be unordered
relative to each other, but still ordered relative to the remaining
members of set1 and set2.  This is _at most_ as much information as
could be gleaned from absolute rankings, and most likely _less_ since
the resulting set may not always be fully ordered.

I don't expect applications to do this, but instead I expect the GSS
framework and/or mechanisms to compute such sets for any apps that
perform application-layer negotiation.

Without a policy concept in the API we'd have N applications
implementing different local policy definition mechanisms based on
absolute cipher suite / mechanism strength numbers.  Whereas by having a
policy concept in the API we force the framework and mechanism
implementors to provide a local policy definition facility and get the
application developers out of that business.  Sounds like a win to me.

I'd like to see a strong argument for using absolute cipher suite /
mechanism strength numbers.  About the only argument for that that I can
think of is that users are used to such measures of strength, therefore
we should stick to what users know.  I think that's a fairly strong
argument for having numeric strength measures.  It's not a strong
argument for not having symbolic policies.  Indeed, not having symbolic
policies creates the possibility of ending up with too many policy
mechanisms.

> pieces of code (which may or may not be linked into the same
> process) cooperate across the API to build a UI. TWAIN does get away
> from the packaging, but the result is not nirvana.

There's not enough detail there for me to understand how relevant TWAIN
is to this discussion.

In any case, here information about standard-defined policies met would
be delivered by the same "package" that delivers any one cipher suite /
mechanism... your analogy to TWAIN, if I understood it, fails.  Locally-
defined policies would be feasible either way, regardless of whether the
API provides for absolute cipher strength numbers or symbolic policies;
local policies must therefore be orthogonal to your analogy.

Nico
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 24 May 2010 19:12:43 +0200

> instead of absolute strength numbers does just that.

Sure. UI translation woes. Basically you never want anyone on the 
server/library side to provide the kind of string that the UI will want 
to present in the user's language.

> [Apologies for the length of the following.  I think it's useful.]

Yes, at least to me. I did not understand how complex the information is.

This sounds as if it would be possible to solve it with just scalar 
numbers and boolean flags, which is just fine in UI-building terms.

So one party gives the other a set (or list, doesn't matter) of cipher 
suites, where each is described as describe e.g. "strength x, 
has-fips-1480-2" (one scalar, one boolean, both defined in the policy 
document). The other party looks at the set it receives, makes its 
decision or builds a UI.

> There's not enough detail there for me to understand how relevant TWAIN

If everyone has their head screwed on right TWAIN is completely 
irrelevant ;)

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 May 2010 13:36:29 -0500

On Mon, May 24, 2010 at 07:12:43PM +0200, Arnt Gulbrandsen wrote:
> server/library side to provide the kind of string that the UI will
> want to present in the user's language.

That's not a problem.  (Well, it can be a problem for servers to
localize, as it requires a) language negotiation in the protocol, b)
L10N APIs that allow multi-threaded servers to localize to multiple
different locales.  But this is a side issue.)  It's never a problem for
libraries to localize.

> Yes, at least to me. I did not understand how complex the information is.

Good.

> numbers and boolean flags, which is just fine in UI-building terms.

What would this look like?

> So one party gives the other a set (or list, doesn't matter) of
> cipher suites, where each is described as describe e.g. "strength x,
> has-fips-1480-2" (one scalar, one boolean, both defined in the
> policy document). The other party looks at the set it receives,
> makes its decision or builds a UI.

Again, there's not multiple parties here, just the user.  The user may
get to select a policy, if... policy allows it :)  Or the user might
only get to observe what policies applied or will apply.

As for negotiation on the wire, nothing changes on the wire relative to
existing protocols.  The application may select policies that a
mechanism must apply, and it may select a set of mechanisms to negotiate
from using policies, but the on-the-wire bits for negotiation do not
change.

> If everyone has their head screwed on right TWAIN is completely

No risk of me looking up TWAIN!  :)

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 May 2010 15:07:35 -0400

--On Monday, May 24, 2010 11:41:34 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> argument for having numeric strength measures.

I don't.  To the extent that users are used to numeric measures of crypto 
strength, I expect they either (1) have only seen values "0" and "56", or 
(2) are likely to compare them in unmeaningful ways (1024 is bigger than 
256, so a product advertised as using "1024-bit encryption" (1024-bit RSA 
plus 40-bit DES) is better than a product advertised as using "256 bit AES 
encryption").

The fact is that the "strength" of a complex authentication mechanism using 
multiple cryptographic algorithms in various ways is simply not a linear 
quantity.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 May 2010 14:27:50 -0500

On Mon, May 24, 2010 at 03:07:35PM -0400, Jeffrey Hutzelman wrote:
> I don't.  [...]

I didn't say it was strong enough...  But since we've seen arguments for
numeric strength measures I'd like to see the rationales, and the above
one is the only one that I could think of.

Perhaps there's another possible rationale: a) there's some strong need
for ordered preference sets and b) we explicitly do not want local
policy.  I can't imagine (b) being true; (a), of course, is, but crypto
strength numbers needn't be the only way to get (a).

>           To the extent that users are used to numeric measures of
> crypto strength, I expect they either (1) have only seen values "0"
> and "56", or (2) are likely to compare them in unmeaningful ways
> (1024 is bigger than 256, so a product advertised as using "1024-bit
> encryption" (1024-bit RSA plus 40-bit DES) is better than a product
> advertised as using "256 bit AES encryption").

I was thinking more of 0, 56, 128 and 256.  But yes, I find this
argument relatively weak, as in weaker than my arguments for symbolic
policies instead :)

> The fact is that the "strength" of a complex authentication
> mechanism using multiple cryptographic algorithms in various ways is
> simply not a linear quantity.

My view exactly.  (Not linear, not constant, not sufficiently useful.
Policy is needed no matter what, therefore I'd like to skip straight to
that answer.)

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 25 May 2010 07:58:18 -0700

I am fine with the charter not specifically stating it will undertake revision of RFC 4422.  I see no burning need to undertake this work and personally rather wait for SASLprep to be sorted.

On the subject of SASLprep, I rather revision of RFC 4013 be worked in NewPrep.  The reason for this is two fold. 1) Expertise: I figure there is better chance of getting both SASL (and general security expertise) and Unicode/StringPrep expertise in the NewPrep forums than the MOGGIES forums.   2) SASLprep is used not only by SASL mechanisms but in various other systems, such as LDAP, I prefer a more neutral forum.

On the subject of "interface for reporting the security strength of GSS-API:  I note that I once wrote an I-D which kinds of relates to this.  <http://www.watersprings.org/pub/id/draft-zeilenga-auth-lvl-02.txt>.   Beyond that, I think this work item is a rat-hole and rather it not be on the charter.  Instead, I suggest folks pursue this on an individual/independent basis if they think they can come up with something useful here.

-- Kurt

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 May 2010 19:07:40 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

I join Martin.  I think that closing sasl and rechartering is disruptive
enough.  I don't think it makes sense to change the name of two WGs.  I
definitely don't think that it makes sense to change to a new mailing
list instead of one of the existing mailing lists.  I don't think the
new name or a desire to have a new name is sufficiently compelling to
change the mailing list.

so:

1) I strongly object to the new wg using a mailing list other than
[email-masked] the old SASL list.
2) I don't think it wise for the new WG to have a name that disagrees
with its mailing list.

As a result I fairly strongly believe the WG should be called kitten or
SASL.