Re: WG Last Call - krb-wg charter update (LDAP)

Sam Hartman wrote:
> Question:
>
> Who would author documents in this space?
> Who would review documents?
> who would implement?
I would at least review the documents.

--
Shawn.

Re: WG Last Call - krb-wg charter update (LDAP)

Shawn M Emery <Shawn.Emery <at> Sun.COM> writes:

> Sam Hartman wrote:
>> Question:
>>
>> Who would author documents in this space?
>> Who would review documents?
>> who would implement?
> I would at least review the documents.

I based Shishi's database interface on the data model draft, and I would
update the implementation if a new version of the document came out with
improvements.  I'd also be willing to review the document.

Note this is only about the data model, I don't personally have a need
for the LDAP document yet.

/Simon

Re: WG Last Call - krb-wg charter update (LDAP)

On 5/31/07, Sam Hartman <hartmans-ietf <at> mit.edu> wrote:
> Question:
>
> Who would author documents in this space?
> Who would review documents?
> who would implement?

I would review and implement.

Enrique

Re: WG Last Call - krb-wg charter update

On May 30, 2007, at 2:36 PM, Douglas E. Engert wrote:

>
> This just came up yesterday in a phone conversation with NASA.
>
> They are looking for a way to carry Level of Assurance information
> in the TGT, especially if PKINIT was used.  See NIST 800-63 for a
> set of guildlines defining the levels.
>
> http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
>
> This might be done as an additional piece of auth data with the level
> or might even be a piece of auth data with the user's certificate.
>
> I talked with Sam today, and he suggested that this would need to be
> added to the charter, so I am sending this in today, hope it is not
> to late.

I support the idea of having some authoritative label like "high",  
"medium", etc.  For it to be useful it needs to be accessible to  
GSSAPI, SSPI, SASL, et cetera clients though.

I oppose the idea of having an RFC of international scope use the US- 
specific definitions in 800-63, except as an illustrative example.   
(That's one of the better documents in the series though.)

I will volunteer to make random, hopefully useful comments on such a  
proposal, but not to author it.  Whether I would implement or deploy  
it is a political decision largely outside my control.

Proposal: FAST as an alternative to RFC 1510ter

<hat role="individual">

Nico, Larry, Tom and I would like to ask the working group to consider
an alternative to the direction we chose for Kerberos Extensions at IETF 53.

The problem with extensions is that few if any implementers plan to
implement them.  There is a lot of complexity for relatively little
gain.  The major things you get from implementing extensions are
support for internationalization, support for ticket extensions and
support for authenticated cleartext.

These are all good to have.  The problem is that the cost seems to be
too high for anyone to schedule the work.

We'd like to find an alternative way to accomplish these goals that is
easier to implement.

We believe that by leveraging the fast proposal we may be able to do
that.  First of all, by combining with fast, we get additional
leverage: fixing preauth is something that people definitely want to
do.

Nico started things off by pointing out that we probably wanted to
include a full kdc req body in fast, not just the client name field.

Then one of us wondered what type of string we should use there: UTF8
or general string.  ANd we realized that we had actually done the
first part of the extensions negotiation.

Re: Proposal: FAST as an alternative to RFC 1510ter

On Wed, Jun 06, 2007 at 04:39:32PM -0400, Sam Hartman wrote:
> Obviously, this is just a sketch of the proposal.  Is this interesting
> enough to dedicate time to discuss in Chicago?

Yes.

I'll note that what you described can also be done with the starttls
proposal.  The whole thing hinges on using tunneling as the negotiation
for extensions.

Nico
--

-- 

Re: Proposal: FAST as an alternative to RFC 1510ter

At Wed, 06 Jun 2007 16:39:32 -0400,
Sam Hartman <hartmans <at> mit.edu> wrote:
> 
> Obviously, this is just a sketch of the proposal.  Is this interesting
> enough to dedicate time to discuss in Chicago?

Yes.

The alternative ticket extensions is most interesting for me.
Its advantage outweighs my uncomfortable feeling for the hack.

--

-- 
KAMADA Ken'ichi <kamada <at> nanohz.org>

Re: Proposal: FAST as an alternative to RFC 1510ter

On Thu, Jun 07, 2007 at 09:09:56AM +0900, KAMADA Ken'ichi wrote:
> At Wed, 06 Jun 2007 16:39:32 -0400,
> Sam Hartman <hartmans <at> mit.edu> wrote:
> > 
> > Obviously, this is just a sketch of the proposal.  Is this interesting
> > enough to dedicate time to discuss in Chicago?
> 
> Yes.
> 
> The alternative ticket extensions is most interesting for me.
> Its advantage outweighs my uncomfortable feeling for the hack.

That's how I feel too.  Gross, but good.

New mailing list and potential BoF: trust anchor management

other implementation of gss_pseudo_random

Hello,

Since gss_pseudo_random for Kerberos V (rfc4402) lacks test vectors  
are there other
implemetations of it that I can do interrop testing with ?

Heimdal have the code living in svn trunk (see htto://www.h5l.se/).

Love