[Ietf-krb-wg] Negotiating DCE style

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[Ietf-krb-wg] Negotiating DCE style

Nico Williams
I see two ways to negotiate DCE style (3-legged AP exchange):

a) the KDC knows whether the service supports it and announces it to
the client via a ticket option (which, incidentally, gets recorded in
ccaches, which is very nice);

b) the initiator sets a flag in the authenticator (either as a GSS
flag or as an authz-data element, since we can't use auth-options,
since that's not authenticated) and if the acceptor understands it
then it will respond with a new form of AP-REP (mainly in that there
would be new fields in the enc part), and if not, well, then the mech
does the standard one round-trip thing.

I'm quite partial to (b), actually.  I don't really like the idea that
the KDC has to know about specific features supported by a principal.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Stefan Metzmacher
Hi Nico,

> I see two ways to negotiate DCE style (3-legged AP exchange):
>
> a) the KDC knows whether the service supports it and announces it to
> the client via a ticket option (which, incidentally, gets recorded in
> ccaches, which is very nice);
>
> b) the initiator sets a flag in the authenticator (either as a GSS
> flag or as an authz-data element, since we can't use auth-options,
> since that's not authenticated) and if the acceptor understands it
> then it will respond with a new form of AP-REP (mainly in that there
> would be new fields in the enc part), and if not, well, then the mech
> does the standard one round-trip thing.
>
> I'm quite partial to (b), actually.  I don't really like the idea that
> the KDC has to know about specific features supported by a principal.
Why are you thinking about that? It's (b) with a GSS flag (GSS_C_DCE_STYLE)

See http://www.ietf.org/rfc/rfc4757.txt.

I think there's no reason to redesign this, as it wouldn't be needed at
all...

metze


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Nico Williams
On Thu, Apr 28, 2011 at 1:48 PM, Stefan (metze) Metzmacher
<[hidden email]> wrote:
> Why are you thinking about that? It's (b) with a GSS flag (GSS_C_DCE_STYLE)
>
> See http://www.ietf.org/rfc/rfc4757.txt.
>
> I think there's no reason to redesign this, as it wouldn't be needed at
> all...

RFC4757 does not describe something that's negotiable.  If the
acceptor doesn't support this flag then things should fail if the
initiator tries to use it.
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Stefan Metzmacher
Hi Nico,

> On Thu, Apr 28, 2011 at 1:48 PM, Stefan (metze) Metzmacher
> <[hidden email]> wrote:
>> Why are you thinking about that? It's (b) with a GSS flag (GSS_C_DCE_STYLE)
>>
>> See http://www.ietf.org/rfc/rfc4757.txt.
>>
>> I think there's no reason to redesign this, as it wouldn't be needed at
>> all...
>
> RFC4757 does not describe something that's negotiable.  If the
> acceptor doesn't support this flag then things should fail if the
> initiator tries to use it.
The acceptor has to support it if implementing DCERPC authtype 16
or offer krb5 via spnego (authtype 9). And it should be used only for
DCERPC (and only because existing clients and servers use it).

metze


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Nico Williams

On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" <[hidden email]> wrote:
> The acceptor has to support it if implementing DCERPC authtype 16
> or offer krb5 via spnego (authtype 9). And it should be used only for
> DCERPC (and only because existing clients and servers use it).

Right. I want to use it for other protocols.  So a new flag and a AP-REP enc part extension.


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Stefan Metzmacher
Am 29.04.2011 07:03, schrieb Nico Williams:
> On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" <[hidden email]>
> wrote:
>> The acceptor has to support it if implementing DCERPC authtype 16
>> or offer krb5 via spnego (authtype 9). And it should be used only for
>> DCERPC (and only because existing clients and servers use it).
>
> Right. I want to use it for other protocols.  So a new flag and a AP-REP enc
> part extension.

Why? It just adds complexity for no gain.

metze


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Luke Howard

On 29/04/2011, at 9:48 AM, Stefan (metze) Metzmacher wrote:

> Am 29.04.2011 07:03, schrieb Nico Williams:
>> On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" <[hidden email]>
>> wrote:
>>> The acceptor has to support it if implementing DCERPC authtype 16
>>> or offer krb5 via spnego (authtype 9). And it should be used only for
>>> DCERPC (and only because existing clients and servers use it).
>>
>> Right. I want to use it for other protocols.  So a new flag and a AP-REP enc
>> part extension.
>
> Why? It just adds complexity for no gain.


You can do away with the replay cache.

-- Luke
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Stefan Metzmacher
Am 29.04.2011 10:02, schrieb Luke Howard:

>
> On 29/04/2011, at 9:48 AM, Stefan (metze) Metzmacher wrote:
>
>> Am 29.04.2011 07:03, schrieb Nico Williams:
>>> On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" <[hidden email]>
>>> wrote:
>>>> The acceptor has to support it if implementing DCERPC authtype 16
>>>> or offer krb5 via spnego (authtype 9). And it should be used only for
>>>> DCERPC (and only because existing clients and servers use it).
>>>
>>> Right. I want to use it for other protocols.  So a new flag and a AP-REP enc
>>> part extension.
>>
>> Why? It just adds complexity for no gain.
>
>
> You can do away with the replay cache.
Can you explain that?

In anyway I think the GSS_C_DCE_STYLE flag should not be used,
as it also has impact on the PDU encoding.

If you need to 3 legs, please add a completely new feature
and don't mix it with existing stuff.

metze


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Greg Hudson
On Fri, 2011-04-29 at 04:10 -0400, Stefan (metze) Metzmacher wrote:
> > You can do away with the replay cache.
>
> Can you explain that?

The first client->server leg of the exchange establishes the client
identity, but could be replayed.  The second leg establishes the server
identity and creates a fresh acceptor subkey (at least for modern
enctypes and implementations).  The third leg proves that the client was
able to decode the acceptor subkey and use it.

If the client is going to send a wrapped message or use channel
bindings, the third leg is sort of unnecessary, depending on the app.
But the app would still see a complete gss_accept_sec_context() after
the second leg, before the client has proved that it's not just a
replay, and in some circumstances the mere ability to fake a successful
authentication is a problem.


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Stefan Metzmacher
Am 29.04.2011 16:06, schrieb Greg Hudson:

> On Fri, 2011-04-29 at 04:10 -0400, Stefan (metze) Metzmacher wrote:
>>> You can do away with the replay cache.
>>
>> Can you explain that?
>
> The first client->server leg of the exchange establishes the client
> identity, but could be replayed.  The second leg establishes the server
> identity and creates a fresh acceptor subkey (at least for modern
> enctypes and implementations).  The third leg proves that the client was
> able to decode the acceptor subkey and use it.
>
> If the client is going to send a wrapped message or use channel
> bindings, the third leg is sort of unnecessary, depending on the app.
> But the app would still see a complete gss_accept_sec_context() after
> the second leg, before the client has proved that it's not just a
> replay, and in some circumstances the mere ability to fake a successful
> authentication is a problem.
Ok, got it.

metze


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] [kitten] Negotiating DCE style

Luke Howard
In reply to this post by Greg Hudson
> The first client->server leg of the exchange establishes the client
> identity, but could be replayed.  The second leg establishes the server
> identity and creates a fresh acceptor subkey (at least for modern
> enctypes and implementations).  The third leg proves that the client was
> able to decode the acceptor subkey and use it.

Just to add to this, my understanding is that the acceptor subkey is always used for GSS_C_DCE_STYLE, regardless of enctype.

-- Luke
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Sam Hartman-5
In reply to this post by Nico Williams


Hi.
Please be aware that neither ap-rep extensions nor DCE style RPC are in
our current charter.


I think it would be problematic to add specifics.  However, if you
wanted to propose text to address the need for the Kerberos replay cache
and you got some folks to indicate support, we could potentially sneak
that in.  However we're late enough in the process you should start with
a specific text proposal.
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Nico Williams
On Fri, Apr 29, 2011 at 10:52 AM, Sam Hartman <[hidden email]> wrote:
> Please be aware that neither ap-rep extensions nor DCE style RPC are in
> our current charter.
>
> I think it would be problematic to add specifics.  However, if you
> wanted to propose text to address the need for the Kerberos replay cache
> and you got some folks to indicate support, we could potentially sneak
> that in.  However we're late enough in the process you should start with
> a specific text proposal.

Good point.

I think this is important.  I want us to do this.  Arguably, since
this may require a GSS req_flag, we could pursue this work in either
KITTEN or KRB-WG.  In any case, my proposed charter text:

  Today Kerberos requires a replay cache to be used in AP exchanges in
almost all cases.  Replay caches are quite complex to implement
correctly, particularly in clustered systems.  High-performance replay
caches are even more difficult to implement.  The WG will pursue
extensions to minimize the need for replay caching, optimize replay
caching, and/or elide the need for replay caching.

To the work items list I'd then add:

 o Make "DCE style" (3-legged AP exchange) negotiable.
 o Add extensions to make replay caching unnecessary for common
application protocols without having to resort to 3-legged AP
exchanges.

We might decide later to not complete the second of those work items,
if we conclude that any related API changes are too complex, say.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Greg Hudson
On Fri, 2011-04-29 at 12:01 -0400, Nico Williams wrote:
> > wanted to propose text to address the need for the Kerberos replay cache
> > and you got some folks to indicate support, we could potentially sneak
> > that in.
[...]
>   Today Kerberos requires a replay cache to be used in AP exchanges in
> almost all cases.  Replay caches are quite complex to implement
> correctly, particularly in clustered systems.  High-performance replay
> caches are even more difficult to implement.  The WG will pursue
> extensions to minimize the need for replay caching, optimize replay
> caching, and/or elide the need for replay caching.

I support this statement.  I'm not yet sure what I think is the best
approach to making replay caches unnecessary, but the options we've
discussed so far seem plausible.


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Sam Hartman-5
>>>>> "Greg" == Greg Hudson <[hidden email]> writes:

    Greg> On Fri, 2011-04-29 at 12:01 -0400, Nico Williams wrote:
    >> > wanted to propose text to address the need for the Kerberos
    >> replay cache > and you got some folks to indicate support, we
    >> could potentially sneak > that in.
    Greg> [...]
    >> Today Kerberos requires a replay cache to be used in AP exchanges
    >> in almost all cases.  Replay caches are quite complex to
    >> implement correctly, particularly in clustered systems.
    >> High-performance replay caches are even more difficult to
    >> implement.  The WG will pursue extensions to minimize the need
    >> for replay caching, optimize replay caching, and/or elide the
    >> need for replay caching.

    Greg> I support this statement.  I'm not yet sure what I think is
    Greg> the best approach to making replay caches unnecessary, but the
    Greg> options we've discussed so far seem plausible.


If there is sufficient support I could see adding a statement like this
to the work items.

Speaking as a chair, Nico's proposed text for the work items is to
proposal-specific and I don't see a way we could get a consensus on it
in time, nor is it the type of charter statement we would make.
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Nico Williams
On Fri, Apr 29, 2011 at 11:31 AM, Sam Hartman <[hidden email]> wrote:
>    Greg> I support this statement.  I'm not yet sure what I think is
>    Greg> the best approach to making replay caches unnecessary, but the
>    Greg> options we've discussed so far seem plausible.
>
> If there is sufficient support I could see adding a statement like this
> to the work items.

So let's ask who's in favor.

> Speaking as a chair, Nico's proposed text for the work items is to
> proposal-specific and I don't see a way we could get a consensus on it
> in time, nor is it the type of charter statement we would make.

Fair enough.  I'd firgured we'd need the work items to be somewhat
more granular than the first paragraph I wrote.  As long as we have
something in the charter that we could use to submit WG I-Ds on this.
If you think the first paragraph of what I wrote achieves that, then
I'm happy.  If not I can propose new text.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Sam Hartman-5
I think that if there is sufficient suppo,support the chairs can take
your first paragraph and turn into work item text.
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Nico Williams
On Fri, Apr 29, 2011 at 11:57 AM, Sam Hartman <[hidden email]> wrote:
> I think that if there is sufficient suppo,support the chairs can take
> your first paragraph and turn into work item text.

OK.  We have Greg's and my support.  We probably have yours as well,
chair hat off.

Anybody else?

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Love Hörnquist Åstrand-4
In reply to this post by Nico Williams

29 apr 2011 kl. 09:01 skrev Nico Williams:

To the work items list I'd then add:

o Make "DCE style" (3-legged AP exchange) negotiable.
o Add extensions to make replay caching unnecessary for common
application protocols without having to resort to 3-legged AP
exchanges.

I would like to see replay caches be to be un-necessary.

Love


_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Ietf-krb-wg] Negotiating DCE style [charter implications]

Simo Sorce
On Fri, 2011-04-29 at 11:02 -0700, Love Hörnquist Åstrand wrote:

>
> 29 apr 2011 kl. 09:01 skrev Nico Williams:
>
> > To the work items list I'd then add:
> >
> > o Make "DCE style" (3-legged AP exchange) negotiable.
> > o Add extensions to make replay caching unnecessary for common
> > application protocols without having to resort to 3-legged AP
> > exchanges.
>
> I would like to see replay caches be to be un-necessary.

Me too, they are extremely painful.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg