Jeffrey Hutzelman | 3 May 00:32 2004
Picon

I-D ACTION:draft-ietf-sasl-saslprep-09.txt (fwd)

Please make sure you review this, folks.
We're planning on depending on it in kerberos-extensions, and it's now very 
close to IESG approval.

-- Jeff

---------- Forwarded Message ----------
Date: Thursday, April 29, 2004 15:53:13 -0400
From: Internet-Drafts <at> ietf.org
To: i-d-announce <at> ietf.org
Subject: I-D ACTION:draft-ietf-sasl-saslprep-09.txt

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-09.txt
	Pages		: 7
	Date		: 2004-4-29
	
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.

(Continue reading)

Jeffrey Altman | 3 May 00:45 2004

Re: I-D ACTION:draft-ietf-sasl-saslprep-09.txt (fwd)

Jeffrey Hutzelman wrote:
Please make sure you review this, folks.
We're planning on depending on it in kerberos-extensions, and it's now very close to IESG approval.

-- Jeff

There is a current issue undergoing discussion on the sasl mailing list
related to the important of Unicode Public Review Issue #29: Normalization Issue

   http://www.unicode.org/review/pr-29.html

"There is a problem in the language of the specification of UAX #15: Unicode Normalization Forms for forms NFC and NFKC. A textual fix is required to make normalization formally self-consistent. Programs that depend on such logical consistency may be subject to security problems until fixed, although as yet we know of no realistic scenarios that would present such problems. The fix will not have an impact on real data found in practice (with the possible exception of test cases for the algorithm itself), because the affected sequences do not constitute well-formed text in any language."

This will have an impact on SASLPrep.  The question being discussed is should SASLPrep
attempt to fix this problem; should we wait for a fix to NamePrep; or should this be
fixed by Unicode.


Tim Alsop | 4 May 19:45 2004
Picon

User to User Kerberos

Hi,
 
Is user to user Kerberos considered to be ok to use, broken or some other status ? I am not refering to u2u with GSS, just u2u with Kerberos tickets. The reason for asking is that this approach is being considered for WS-Security (Web Services Security) standard being progressed within OASIS WSS TC.
 
Thanks, Tim.
 
Sam Hartman | 4 May 22:06 2004
Picon

Re: User to User Kerberos

>>>>> "Tim" == Tim Alsop <Tim.Alsop <at> CyberSafe.Ltd.UK> writes:

    Tim> Hi, Is user to user Kerberos considered to be ok to use,
    Tim> broken or some other status ? I am not refering to u2u with
    Tim> GSS, just u2u with Kerberos tickets. The reason for asking is
    Tim> that this approach is being considered for WS-Security (Web
    Tim> Services Security) standard being progressed within OASIS WSS
    Tim> TC.

It is very challenging to  get right, but is not broken.

I'd recommend that any use of it be reviewed by this working group or
at least by the IETF security area.

Tim Alsop | 4 May 23:29 2004
Picon

RE: User to User Kerberos

Sam,

Thanks. I will recommend to the Oasis working group involved to pass their document to this working group for feedback once it is in a suitable form.

Take care,

Tim.

-----Original Message-----
From: Sam Hartman [mailto:hartmans <at> mit.edu]
Sent: 04 May 2004 21:06
To: Tim Alsop
Cc: ietf-krb-wg <at> anl.gov
Subject: Re: User to User Kerberos

>>>>> "Tim" == Tim Alsop <Tim.Alsop <at> CyberSafe.Ltd.UK> writes:

    Tim> Hi, Is user to user Kerberos considered to be ok to use,
    Tim> broken or some other status ? I am not refering to u2u with
    Tim> GSS, just u2u with Kerberos tickets. The reason for asking is
    Tim> that this approach is being considered for WS-Security (Web
    Tim> Services Security) standard being progressed within OASIS WSS
    Tim> TC.

It is very challenging to  get right, but is not broken.

I'd recommend that any use of it be reviewed by this working group or
at least by the IETF security area.

Sam Hartman | 6 May 19:38 2004
Picon

pkinit apathy


We don't seem to be making much progress on pkinit.  I know I'm
waiting for a few things from other people; is anyone waiting on
something from me?

I am waiting on a response to the authorization data discussion from
the Cable Labs people.  Does Nico's clarification help people
understand why you would want that data to be a MUST implement?  If
you do understand why someone might want that to be a MUST, do you
agree it should in fact be a MUST?  If not, why not?

I'm waiting to hear on the whole OCSP issue from someone at Microsoft.
How important do they believe it is to standardize now?

I'm also concerned that Love's comments haven't been resolved.  I do
not fully understand them, but I do understand them enough to believe
that they need to be dealt with.

I'm also a bit dubious that we actually got to consensus on text
dealing with names and the AS reply.  IN this instance, I think our
lack of consensus stems from too many acceptable options and a need to
pick one.

--Sam

Brian Tung | 6 May 21:21 2004
Picon

Re: pkinit apathy

Sam Hartman wrote:
> We don't seem to be making much progress on pkinit.  I know I'm
> waiting for a few things from other people; is anyone waiting on
> something from me?
> 
> I am waiting on a response to the authorization data discussion from
> the Cable Labs people.  Does Nico's clarification help people
> understand why you would want that data to be a MUST implement?  If
> you do understand why someone might want that to be a MUST, do you
> agree it should in fact be a MUST?  If not, why not?
> 
> I'm waiting to hear on the whole OCSP issue from someone at Microsoft.
> How important do they believe it is to standardize now?
> 
> I'm also concerned that Love's comments haven't been resolved.  I do
> not fully understand them, but I do understand them enough to believe
> that they need to be dealt with.
> 
> I'm also a bit dubious that we actually got to consensus on text
> dealing with names and the AS reply.  IN this instance, I think our
> lack of consensus stems from too many acceptable options and a need to
> pick one.

I know I'm working out from under a mountain of papers.  Sorry about not
keeping active in the prior discussion; I should be better in the coming
days.

Brian Tung <brian <at> isi.edu>

Love | 6 May 22:08 2004
Picon
Picon

Re: pkinit apathy


hartmans <at> mit.edu (Sam Hartman) writes:

> We don't seem to be making much progress on pkinit.

I'm almost considering hijacking the document and start editing myself (no
offence meant to Brian). I think it should be an implementor that is
(co-)editor to the document, they should be interested in getting the draft
completed.

Love

Ken Raeburn | 6 May 23:50 2004
Picon

comments on pkinit 19

Minor formatting:

Section 3, list of extensions, the number "2" is printed twice, once 
with the (second) item and once against the left margin.

Section 3, list of extensions, item 3, I'm seeing "KDC?s" and 
"client?s".  Are you using "Microsoft quotes" instead of ASCII in this 
document?

Section 3.2.2, description of timestamps, "MUSTreturn" needs a space.

Section 3.2.2, "Enxtended Key Usage" typo.

General Kerberos protocol issues:

Should preauth systems in general be adding to the Kerberos error code 
list?  Or should we have a way of attaching a tuple of { preauth system 
id, preauth-system-specific error code } to an error reply?

PK-INIT crypto stuff:

Section 3.1.x last paragraph, last sentence would seem to indicate that 
any new encryption system to be used with the PK bits must get a new 
Kerberos cryptosystem number assigned.  Weren't the existing numbers 
going to be used only for backwards compatibility, and new encryption 
systems listed only by OID?  (Sorry, I've been a bit preoccupied with 
some other work and non-work activities, and haven't followed the 
PKINIT discussions much lately.)

Section 3.2.3, seed generation:

The case where len(seed) < k should be addressed, if only to explicitly 
disallow combinations of key type and "p" value where it could happen.  
It's not likely to with existing cryptosystems, but I bet I could 
invent a cryptosystem fully compliant with the crypto framework, 
perhaps based on public key crypto, for which the seed would need to be 
very large.  (Not a fast one, perhaps, but it doesn't need to be 
particularly desirable to demonstrate the existence of a problem.)

I'd suggest ending the paragraph discussing random-to-key with "for 
example" and dropping those words from the "1" paragraph following, to 
make it clear that both (1) and (2) are examples, not normative 
specifications.

Love | 7 May 23:11 2004
Picon
Picon

Re: comments on pkinit 19


Ken Raeburn <raeburn <at> mit.edu> writes:

> General Kerberos protocol issues:
>
> Should preauth systems in general be adding to the Kerberos error code
> list?  Or should we have a way of attaching a tuple of { preauth
> system id, preauth-system-specific error code } to an error reply?

I say they shouldn't, put since PK-INIT does and it already exsists
implementaitons, just let pk-init do it.

> PK-INIT crypto stuff:
>
> Section 3.1.x last paragraph, last sentence would seem to indicate
> that any new encryption system to be used with the PK bits must get a
> new Kerberos cryptosystem number assigned.  Weren't the existing
> numbers going to be used only for backwards compatibility, and new
> encryption systems listed only by OID?  (Sorry, I've been a bit
> preoccupied with some other work and non-work activities, and haven't
> followed the PKINIT discussions much lately.)

Yes, it should be oid and not kcrypto numbers since they are CMS
types. This apparently been discussioned already, its just noone that have
send text to Brian. Here is proposal to text:

    AuthPack ::= SEQUENCE {
        pkAuthenticator         [0] PKAuthenticator,
        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
        supportedCmsTypes	[2] SEQUENCE OF AlgorithmIdentifier
        ...
    }

[...]
supportedCmsTypes are those CMS types that are supported by the client CMS
system.

> Section 3.2.3, seed generation:
>
> The case where len(seed) < k should be addressed, if only to
> explicitly disallow combinations of key type and "p" value where it
> could happen.  It's not likely to with existing cryptosystems, but I
> bet I could invent a cryptosystem fully compliant with the crypto
> framework, perhaps based on public key crypto, for which the seed
> would need to be very large.  (Not a fast one, perhaps, but it doesn't
> need to be particularly desirable to demonstrate the existence of a
> problem.)

I propose to deal with in that way that it failes. The kdc is simply not
required to deal with that case.

> I'd suggest ending the paragraph discussing random-to-key with "for
> example" and dropping those words from the "1" paragraph following, to
> make it clear that both (1) and (2) are examples, not normative
> specifications.

I think they should be (1) and (2) should just be removed. random-to-key is
described in kcrypto, no need to rehash it here.

Love


Gmane