headers
Liqiang(Larry) Zhu | 2 Mar 2007 13:14
Picon
Favicon

RE: draft-ietf-krb-wg-anon-02.txt

Ken Raeburn wrote:
>> Jeffrey Hutzelman wrote:
>> BTW, on reflection, I think -naming needs to choose terminology  
>> other than "reserved".  A "reserved" realm name is one that is not  
>> domain-style, X.500, or "other"; overloading the terminology is  
>> going to cause confusion.

> Maybe "special" or something?

I changed this to "well-known".

--larry

-----Original Message-----
From: Ken Raeburn [mailto:raeburn <at> MIT.EDU] 
Sent: Wednesday, February 28, 2007 12:24 PM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; ietf-krb-wg <at> anl.gov
Subject: Re: draft-ietf-krb-wg-anon-02.txt

On Feb 28, 2007, at 11:23, Jeffrey Hutzelman wrote:
> Aside from the heirarchical meaning of a null subfield, DOMAIN-X500- 
> COMPRESS appears to treat realm names as strings.  So, "FOO." at  
> the start of the transited path would mean "FOO.RESERVED:WHATEVER",  
> which is a "reserved" (illegal) realm name, since it contains both  
> a colon and a dot before the colon.

Yes, you're right.  It looks like it's described for any strings,  
it's just optimized for domain and X.500.  Since you wouldn't want to  
be describing invalid realm names, there are just some places where
(Continue reading)

Permalink | Reply | 0 comments |
headers
Liqiang(Larry) Zhu | 2 Mar 2007 13:39
Picon
Favicon

RE: Comments on draft-ietf-krb-wg-naming-01.txt

Jeffrey Hutzelman wrote:

> + Make it clear that all principal names involving a reserved realm
name
>  are reserved.

Done.

   Unless otherwise specified, all principal names involving a well-
   known realm name are reserved, and if a reserved principal name is
   used but not supported, authentication MUST fail with the code
   KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN.

            KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN          TBA
                 -- A reserved Kerberos principal name is used but not
                 -- supported.

   There is no accompanying error data defined in this document for this
   error.

>+ Clarify what it means for reserved names to be critical...
>  - Must the TGS reject requests where the client principal is
reserved?
>  - Must application servers reject AP-REQ's where the client principal
>    is reserved?
>  - What is the handling of reserved service principal names?

   The AS and the application server MUST reject the authentication
   attempt if a well-known realm name is used as the client realm or the
   server realm but not supported.  The TGS [RFC4120] MAY reject the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Hartman | 2 Mar 2007 20:26
Picon
Favicon

draft-ietf-krb-wg-preauth-fw-04.txt and EKE patent


Folks, I wanted to ask the working group to carefully consider how
FAST factors may interact with the EKE patent.  As you will recall,
FAST factors are a way that a client can establish a protected channel
for key exchange with a KDC.  They also include a mechanism so that
the reply key is wrapped in an ephemeral key after being wrapped in a
client's long-term key.  This double encryption allows a KDC to prove
that it is the right KDC while protecting against online dictionary
attacks.

I'm concerned that EKE may cover some or all of this.  However I'm not
familiar enough that I feel comfortable making a third party IPR
disclosure.  I'd appreciate it if the working group would consider
this situation and if members of the working group would do whatever
analysis they believe appropriate.
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-zhu-pkinit-ecc-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Kerberos Working Group of the IETF.

	Title		: ECC Support for PKINIT
	Author(s)	: L. Zhu, et al.
	Filename	: draft-zhu-pkinit-ecc-03.txt
	Pages		: 11
	Date		: 2007-3-5
	
This document describes the use of Elliptic Curve certificates,
   Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
   (ECDH) key agreement within the framework of PKINIT - the Kerberos
   Version 5 extension that provides for the use of public key
   cryptography.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zhu-pkinit-ecc-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-zhu-pkinit-ecc-03.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-krb-wg-anon-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Kerberos Working Group of the IETF.

	Title		: Anonymity Support for Kerberos
	Author(s)	: L. Zhu, et al.
	Filename	: draft-ietf-krb-wg-anon-03.txt
	Pages		: 11
	Date		: 2007-3-5
	
This document defines extensions to the Kerberos protocol for the
   Kerberos client to authenticate the Kerberos Key Distribution Center
   and the Kerberos server, without revealing the client's identity.
   These extensions can be used to secure communication between the
   anonymous client and the server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-anon-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-krb-wg-anon-03.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-krb-wg-naming-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Kerberos Working Group of the IETF.

	Title		: Additional Kerberos Naming Constraints
	Author(s)	: L. Zhu
	Filename	: draft-ietf-krb-wg-naming-02.txt
	Pages		: 7
	Date		: 2007-3-5
	
This document defines new naming constraints for well-known Kerberos
   principal name and well-known Kerberos realm names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-naming-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-krb-wg-naming-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Liqiang(Larry) Zhu | 6 Mar 2007 01:57
Picon
Favicon

RE: Comments on draft-ietf-krb-wg-naming-01.txt

The "reserved" name is now called "well-known" names, based on comments
from Jeff and Ken that the word reserved itself was reserved.

http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-naming-02.txt

Aaron D. Jaggard wrote:
> Also, in the security considerations, what about "Names MUST [or
> SHOULD] not be reused."  instead of "Care MUST be taken to avoid
> accidental reuse of names."

This is fine. Thanks,

--larry

-----Original Message-----
From: aaron.d.jaggard <at> gmail.com [mailto:aaron.d.jaggard <at> gmail.com] On
Behalf Of Aaron D. Jaggard
Sent: Monday, March 05, 2007 8:04 AM
To: Liqiang(Larry) Zhu; ietf-krb-wg <at> anl.gov
Cc: adj <at> math.tulane.edu
Subject: Re: Comments on draft-ietf-krb-wg-naming-01.txt

I'm not able to find a definition in the document for "well-known
realm name"---it seems that if there are "MUST" requirements
conditioned on this term then it should have an unambiguous definition
(explicitly or by reference) in the document.

>    The AS and the application server MUST reject the authentication
>    attempt if a well-known realm name is used as the client realm or
the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 6 Mar 2007 23:40
Picon
Favicon

What preauth mechs?

As I mentioned in my last note, Sam has convinced me that rather than an 
open-ended "work on any preauth" item or a much more limited "evaluate and 
propose, but don't do any work", we should plan to charter with a specific 
list of mechanisms to work on.  That leaves us with the task of decidin 
what should be in that list.

Of course, we're not talking only about "preauthentication" in the 
traditional sense, nor are we limited to extensions that make use of 
PA-DATA.  What we are talking about is anything that is designed to modify 
or augment the initial authentication process in order to protect users' 
passwords or eliminate their use altogether.

We've seen a number of items, some of which were old items in this WG, and 
some of which are brand new.  I've listed below all of the current 
proposals I can remember; please speak up if you have one not listed.  Note 
that there is some overlap between some of these:

    draft-ietf-krb-wg-preauth-framework-04.txt
    draft-ietf-krb-wg-hw-auth-04.txt
    draft-richards-otp-kerberos-01.txt

What I'd like to hear from the working group is comments on which of these 
should or should not be adopted, and why, and who is willing to contribute 
to and review them.

-- Jeff
Permalink | Reply | 3 comments |
headers
Jeffrey Hutzelman | 6 Mar 2007 23:40
Picon
Favicon

Charter discussion

It is time to resume our charter discussion.  Based on discussions with Sam 
and comments received at the last meeting, I've refined my charter update 
proposal; the latest version can be found at the end of this message.  The 
primary open issues are these:

(1) Is there any interest in advancing Kerberos V5.2, PKINIT, and/or the
    GSS-API mechanism beyond Proposed?  If these items are not important
    to anyone, or if there is no one to work on them, then we will need to
    drop them from the charter.

(2) Rather than an open-ended task to work on any preauth proposal that
    comes along, we should have a specific list of mechanisms on which
    we will focus.  That means we need to decide which mechanisms should
    be in that list.  I'm starting a separate thread on that topic.

(3) Do we want to adopt Simon's STARTTLS proposal?

(4) Do we want to adopt a work item to examine cross-realm issues?

(5) Do we want to adopt the data model / LDAP schema / admin work?

(6) Milestones

-- Jeff

===== Proposed Charter =====

Kerberos over the years has been ported to virtually every operating
system.  There are at least two open source versions, with numerous
commercial versions based on these and other proprietary implementations.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richards, Gareth | 7 Mar 2007 13:31

RE: What preauth mechs?

I would give a vote for draft-richards-otp-kerberos-01.txt.  

We remain committed to continue driving the OTP work and so will be
wlling to contribute should it become part of the charter/a work item
for the group.

> -----Original Message-----
> From: owner-ietf-krb-wg <at> mailhost.anl.gov 
> [mailto:owner-ietf-krb-wg <at> mailhost.anl.gov] On Behalf Of 
> Jeffrey Hutzelman
> Sent: 06 March 2007 22:41
> To: ietf-krb-wg <at> anl.gov
> Cc: Jeffrey Hutzelman
> Subject: What preauth mechs?
> 
> As I mentioned in my last note, Sam has convinced me that 
> rather than an open-ended "work on any preauth" item or a 
> much more limited "evaluate and propose, but don't do any 
> work", we should plan to charter with a specific list of 
> mechanisms to work on.  That leaves us with the task of 
> decidin what should be in that list.
> 
> Of course, we're not talking only about "preauthentication" 
> in the traditional sense, nor are we limited to extensions 
> that make use of PA-DATA.  What we are talking about is 
> anything that is designed to modify or augment the initial 
> authentication process in order to protect users' 
> passwords or eliminate their use altogether.
> 
> We've seen a number of items, some of which were old items in
(Continue reading)

Permalink | Reply | 0 comments |

Gmane