Subject: 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 Altman <[email-masked]>
Date: Tue, 18 May 2010 15:29:38 -0400

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

I think the charter is fine but I too object to the name.
Kitten was funny because the predecessor has the acronym of CAT.
I don't think MOGGIES is funny. Perhaps if you figured out how to
turn it into DOGGIES or PUPPIES.

I would much prefer a working group name that had an easy to understand
meaning at first glance.

Jeffrey Altman

---

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

> turn it into DOGGIES or PUPPIES.

KITTEN wasn't an acronym...

A completely uncreative acronym:

 - SAGSS (Simple Authentication and GSS)

Slightly more creative acronym:

 - 2PALS (Two Peer Application Layer Security)

   (This one is kinda neat, if I do say so myself, though it could be
   seen to conflict with TLS.)

Funny WG names in the KITTEN tradition:

 - GASSS (Generic And Simple Security Services)

 - SASSY (not an acronym)

 - anything like TIGER, LION, ... (KITTEN, "growed up")

 - HELLO [KITTy]

I like a fair number (four) of the above, and not just 'cause I came up
with them :)

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: 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: 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: 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: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 22 May 2010 11:22:32 +0200

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.

> Second, do we want to encourage users and/or developers to make 
> relative cipher suite strength comparisons?

Other than "Pick the best?"

Arnt

---

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

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 31 May 2010 09:29:56 +0200

> turn it into DOGGIES or PUPPIES.

Yeah MOGGIES sounds like a fetish of some kind...

---

From: Leif Johansson <[email-masked]>
Date: Mon, 31 May 2010 09:30:53 +0200

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

But what _is_ a moggy? Is it a feline?