Re: DRAFT krb-wg minutes for IETF-62

On Thursday, March 10, 2005 04:06:49 PM -0500 Jeffrey Hutzelman 
<jhutz <at> cmu.edu> wrote:

> Attached below are DRAFT minutes for yesterday's meeting; they are also
> available at http://grand.central.org/krb-wg/ietf62/krb-minutes.html
>
> Please sent any updates or corrections to me; I will make changes to the
> online copy as needed, and post another draft here in a week or so.
>
> Thanks to Jeff Altman for doing an excellent job taking these minutes.

I've received all of one comment on these minutes (which has been 
addressed), so they must have been pretty fabulous.  The deadline for 
submission of minutes is April 8.  Unless I receive more comments by the 
close of business on Monday, April 4, I am sending these in as-is.

-- Jeff

Re: draft-zhu-kerb-enctype-nego: enctype negotiation

Was the option for GSS-API's PROT_READY entirely removed from krb5-cfx,
or will this paragraph need a "caveat" to indicate that the server may
have to process messages sent by initiator protected under the original,
initiator-asserted subsession key in case the initiator used the
PROT_READY feature in GSS-API.

-Martin

Liqiang wrote:
> 
> At IETF 62, we agreed to add text to say that the server-asserted subkey
> must win.
> 
> I proposed to change section 3 to have the following:
> 
>    If the EtypeList is present and the server prefers an enctype from
>    the client's enctype list over that of the AP-REQ authenticator
>    subkey (if that is present) or the service ticket session key, the
>    server MUST create a subkey using that enctype.  This negotiated
>    subkey is sent in the subkey field of AP-REP message and it MUST be
>    used for subsequent communication.
> 
>    This negotiation extension MUST NOT be used when the client does not
>    expect the subkey in the AP-REP message from the server.
> 
> -- Larry
> 
> 
> 

Re: draft-zhu-kerb-enctype-nego: enctype negotiation

On Mon, Apr 04, 2005 at 04:22:35PM +0200, Martin Rex wrote:
> 
> Was the option for GSS-API's PROT_READY entirely removed from krb5-cfx,
> or will this paragraph need a "caveat" to indicate that the server may
> have to process messages sent by initiator protected under the original,
> initiator-asserted subsession key in case the initiator used the
> PROT_READY feature in GSS-API.

CFX has text on PROT_READY.

Re: draft-zhu-kerb-enctype-nego: enctype negotiation

>>>>> "Martin" == Martin Rex <martin.rex <at> sap.com> writes:

    Martin> Was the option for GSS-API's PROT_READY entirely removed
    Martin> from krb5-cfx, or will this paragraph need a "caveat" to
    Martin> indicate that the server may have to process messages sent
    Martin> by initiator protected under the original,
    Martin> initiator-asserted subsession key in case the initiator
    Martin> used the PROT_READY feature in GSS-API.

Being a bit more verbose than Nico, CFX has text on prot_ready already
pointing out exactly this issue.

Re: draft-zhu-kerb-enctype-nego: enctype negotiation

Sam Hartman wrote:
> 
> >>>>> "Martin" == Martin Rex <martin.rex <at> sap.com> writes:
> 
>     Martin> Was the option for GSS-API's PROT_READY entirely removed
>     Martin> from krb5-cfx, or will this paragraph need a "caveat" to
>     Martin> indicate that the server may have to process messages sent
>     Martin> by initiator protected under the original,
>     Martin> initiator-asserted subsession key in case the initiator
>     Martin> used the PROT_READY feature in GSS-API.
> 
> Being a bit more verbose than Nico, CFX has text on prot_ready already
> pointing out exactly this issue.

I think that the term "subsequent communication" might be too vague in

:   This negotiation extension MUST NOT be used when the client does not
:   expect the subkey in the AP-REP message from the server.

without any examples/hints.

From the discussion of PROT_READY, it seems to me that it is somewhat
uncommon for traditional kerberized apps to have an initiator use
message protection before an authentication exchange that did
involve AP_REP is complete.

I'm a little worried about the locality of relevant information.
a "MUST" is pretty strong.  If a must has any caveats (like uncertainty
at what point it can really be enforced), then this should be directly
mentioned in a sufficiently clear fashion, so that it does not lead

Re: enctype negotiation and GSS naming extensions

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams <at> sun.com> writes:

    Nicolas> At MN I said I did not oppose Larry's Kerberos enctype
    Nicolas> negotiation proposal.

    Nicolas> I'm less sure now.

    Nicolas> You may recall that at the interim meeting at Boulder we
    Nicolas> decided that extensions would add a typed hole, distinct
    Nicolas> from authorization-data, to the authenticator and AP-REP.
    Nicolas> We'd argued over whether it was proper to overload
    Nicolas> authorization-data and decided that it was not.

    Nicolas> Larry's proposal overloads authorization-data by using it
    Nicolas> to transport a client's enctype proposal to the server.

    Nicolas> I am still inclined to agree that enctype negotiation is
    Nicolas> an allowable overloading of authorization-data, but the
    Nicolas> GSS-API naming extensions we're discussing at the KITTEN
    Nicolas> WG give me pause.

I've thought about this for a while and I also think it is reasonable
overloading if only because we don't want to tell Larry to wait for
extensions.

--Sam

Re: enctype negotiation and GSS naming extensions

On Tue, Apr 05, 2005 at 09:13:33AM -0400, Sam Hartman wrote:
>     Nicolas> I am still inclined to agree that enctype negotiation is
>     Nicolas> an allowable overloading of authorization-data, but the
>     Nicolas> GSS-API naming extensions we're discussing at the KITTEN
>     Nicolas> WG give me pause.
> 
> I've thought about this for a while and I also think it is reasonable
> overloading if only because we don't want to tell Larry to wait for
> extensions.

Ok, and as a one-time thing a mechanism implementation could filter
enctype negotiation AD out in the GSS naming interfaces.

I have no remaining objections to Larry's proposal.

Nico
--

-- 

Re: enctype negotiation and GSS naming extensions

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams <at> sun.com> writes:

    Nicolas> On Tue, Apr 05, 2005 at 09:13:33AM -0400, Sam Hartman
    Nicolas> wrote: I am still inclined to agree that enctype
    Nicolas> negotiation is an allowable overloading of
    Nicolas> authorization-data, but the GSS-API naming extensions
    Nicolas> we're discussing at the KITTEN WG give me pause.
    >>  I've thought about this for a while and I also think it is
    >> reasonable overloading if only because we don't want to tell
    >> Larry to wait for extensions.

    Nicolas> Ok, and as a one-time thing a mechanism implementation
    Nicolas> could filter enctype negotiation AD out in the GSS naming
    Nicolas> interfaces.

Could but should not.

[Fwd: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt]

The following Internet-Drafts related to the Kerberos WG
are now in WGLC within the Kitten WG.

From: Jeffrey Altman <jaltman <at> columbia.edu>
Subject: Working Group Last Call: draft-ietf-kitten-krb5-gssapi-prf-02.txt and draft-ietf-kitten-gssapi-prf-02.txt
Date: 2005-04-14 19:12:16 GMT

Today begins a Working Group Last Call on the working group
drafts:

 * draft-ietf-kitten-gssapi-prf-02.txt
 * draft-ietf-kitten-krb5-gssapi-prf-02.txt

There are known issues related to ID-Nits failures which will
be addressed at the end of the working group last call period
prior to submission to the IESG.

* draft-ietf-kitten-gssapi-prf-02.txt:

  - The IANA Considerations section is missing

  - The boilerplate must be updated to RFC 3978

  - The IPR disclosure must be in conformance with BCP 79.

[FWD: Comments on the WSS Kerberos Token Profile 1.0, Draft 5]

The OASIS Web Services Security Kerberos Token Profile 1.0, Draft 5,
recently came to my attention.  I have read and reviewed the document
and posted my comments to the WSS comment list.

Other participants of the IETF KRB and/or KITTEN WGs may be interested
in reviewing said draft specification.

I note that the IETF has no liaison to OASIS, nor does the OASIS WSS TC
have a liaison to the IETF.

Nico

----- Forwarded message from Nicolas Williams <Nicolas.Williams <at> sun.com> -----

Date: Thu, 14 Apr 2005 16:35:22 -0500
From: Nicolas Williams <Nicolas.Williams <at> sun.com>
To: wss-comment <at> lists.oasis-open.org
Subject: Comments on the WSS Kerberos Token Profile 1.0, Draft 5

The Web Services Security Kerberos Token Profile 1.0, Draft 5 appears,
in some ways to be incomplete.

Additionally, I believe it is quite unfortunate that the Kerberos V
GSS-API mechanism was not used instead.  I can understand that the lack
of a keying facility may well have led to this unfortunate design, but
you should know that the IETF KITTEN WG is currently holding a Working
Group Last call on a GSS-API extension for (and corresponding Kerberos V
mechanism specification of) a pseudo-random function keyed internally by
a GSS-API security context.  This new feature of both, the GSS-API and
the Kerberos V GSS-API mechanism should provide all the functionality