[kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

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

[kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

Internet-Drafts

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Next Generation of the IETF.

        Title           : Anonymity Support for Kerberos
        Authors         : Larry Zhu
                          Paul Leach
                          Sam Hartman
                          Shawn Emery
        Filename        : draft-ietf-kitten-rfc6112bis-01.txt
        Pages           : 17
        Date            : 2016-07-26

Abstract:
   This document defines extensions to the Kerberos protocol to allow a
   Kerberos client to securely communicate with a Kerberos application
   service without revealing its identity, or without revealing more
   than its Kerberos realm.  It also defines extensions that allow a
   Kerberos client to obtain anonymous credentials without revealing its
   identity to the Kerberos Key Distribution Center (KDC).  This
   document updates RFCs 4120, 4121, and 4556.  This document obsoletes
   RFC 6112 and reclassifies that document as historic.  RFC 6112
   contained errors and the protocol described in that specification is
   not interoperable with any known implementation.  This specification
   describes a protocol that interoperates with multiple
   implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc6112bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc6112bis-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

Greg Hudson
On 07/26/2016 03:38 PM, [hidden email] wrote:
> Filename        : draft-ietf-kitten-rfc6112bis-01.txt

This revision appears to be editorial, and would be unlikely to affect
an implementation.  I do not have any substantive protocol concerns, but
I do have some minor issues with some of the new wording.

In section 7, "To ensure that an attacker cannot create a channel with a
given name" was changed to "To ensure that an attacker cannot create a
channel by observing exchanges."  The original wording may have used
"name" in a non-intuitive way, but I think the new wording is more
wrong.  The threat is that a MITM attacker might create two channels
with the same ticket session key (known to the attacker); the new
wording suggests that the threat comes from a passive attacker.

In this text:

    Such authorization data, if included in the anonymous ticket, would
    disclose the that the client is a member of the group observed.

After the changes, there is an extra "the" before "that".

In this new block of text:

    This protocol provides a binding between the party which
    generated the session key and the DH exchange used to generate
    they reply key.  Hypothetically, if the KDC did not use
    PA-PKINIT-KX, the client and KDC would perfrom a DH key
    exchange to determine a shared key, and that key would be used
    as a reply key.  The KDC would then generate a ticket with a
    session key encrypting the reply with the DH agreement.  A MITM
    attacker would just decrypt the session key + ticket using the
    DH key from the attacker and KDC DH exchange, and re-encrypt it
    using the key from the attacker and client DH exchange, while
    keeping a copy of the session key and ticket.  By requiring the
    session key in a way that can be verified by the client, this
    protocol binds the ticket to the DH exchange and prevents the
    MITM attack.

"perfrom" should be "perform".  "session key + ticket" should be
"session key and ticket".  It might be clearer to say "attacker-KDC DH
exchange" than "attacker and KDC DH exchange", and similarly
"attacker-client DH exchange".

"By requiring the session key in a way that..." is not grammatical.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

Shawn M Emery

Thanks for your review.  Comments in-line.

On 08/ 2/16 10:25 AM, Greg Hudson wrote:
On 07/26/2016 03:38 PM, [hidden email] wrote:
	Filename        : draft-ietf-kitten-rfc6112bis-01.txt
This revision appears to be editorial, and would be unlikely to affect
an implementation.  I do not have any substantive protocol concerns, but
I do have some minor issues with some of the new wording.

In section 7, "To ensure that an attacker cannot create a channel with a
given name" was changed to "To ensure that an attacker cannot create a
channel by observing exchanges."  The original wording may have used
"name" in a non-intuitive way, but I think the new wording is more
wrong.  The threat is that a MITM attacker might create two channels
with the same ticket session key (known to the attacker); the new
wording suggests that the threat comes from a passive attacker.

Yes, the key word "observing" indicates a passive state.  How about?:

To ensure that an attacker cannot create a channel by obtaining key exchanges between the client and KDC, it is desirable that neither the KDC nor the client unilaterally determine the ticket session key.

In this text:

    Such authorization data, if included in the anonymous ticket, would
    disclose the that the client is a member of the group observed.	

After the changes, there is an extra "the" before "that".

Done.

In this new block of text:

    This protocol provides a binding between the party which
    generated the session key and the DH exchange used to generate
    they reply key.  Hypothetically, if the KDC did not use
    PA-PKINIT-KX, the client and KDC would perfrom a DH key
    exchange to determine a shared key, and that key would be used
    as a reply key.  The KDC would then generate a ticket with a
    session key encrypting the reply with the DH agreement.  A MITM
    attacker would just decrypt the session key + ticket using the
    DH key from the attacker and KDC DH exchange, and re-encrypt it
    using the key from the attacker and client DH exchange, while
    keeping a copy of the session key and ticket.  By requiring the
    session key in a way that can be verified by the client, this
    protocol binds the ticket to the DH exchange and prevents the
    MITM attack.

"perfrom" should be "perform".  "session key + ticket" should be
"session key and ticket".

Done.

It might be clearer to say "attacker-KDC DH
exchange" than "attacker and KDC DH exchange", and similarly
"attacker-client DH exchange".

Agreed.

"By requiring the session key in a way that..." is not grammatical.


How about?:

This protocol binds the ticket to the DH exchange and prevents the MITM attack by requiring the session key in a way that can be verified by the client.

Thanks again for your review.

Shawn.
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

Greg Hudson
On 08/16/2016 12:12 AM, Shawn M Emery wrote:

>> In section 7, "To ensure that an attacker cannot create a channel with a
>> given name" was changed to "To ensure that an attacker cannot create a
>> channel by observing exchanges."  The original wording may have used
>> "name" in a non-intuitive way, but I think the new wording is more
>> wrong.  The threat is that a MITM attacker might create two channels
>> with the same ticket session key (known to the attacker); the new
>> wording suggests that the threat comes from a passive attacker.
>
> Yes, the key word "observing" indicates a passive state.  How about?:
>
> To ensure that an attacker cannot create a channel by obtaining key
> exchanges between the client and KDC, it is desirable that neither the
> KDC nor the client unilaterally determine the ticket session key.

That still suggests a passive attacker to me.  I suggest:

"To ensure that an active attacker cannot create separate channels to
the client and KDC with the same known key, it is desirable that neither
the KDC nor the client unilaterally determine the ticket session key."

>> "By requiring the session key in a way that..." is not grammatical.
>>
>
> How about?:
>
> This protocol binds the ticket to the DH exchange and prevents the MITM
> attack by requiring the session key in a way that can be verified by the
> client.

I believe that change just reverses the two main clauses of the sentence
without eliminating the grammar error.  You could say "requiring the
session key to be created in a way...".

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

Shawn M Emery
On 08/17/16 09:58 AM, Greg Hudson wrote:

> On 08/16/2016 12:12 AM, Shawn M Emery wrote:
>>> In section 7, "To ensure that an attacker cannot create a channel with a
>>> given name" was changed to "To ensure that an attacker cannot create a
>>> channel by observing exchanges."  The original wording may have used
>>> "name" in a non-intuitive way, but I think the new wording is more
>>> wrong.  The threat is that a MITM attacker might create two channels
>>> with the same ticket session key (known to the attacker); the new
>>> wording suggests that the threat comes from a passive attacker.
>> Yes, the key word "observing" indicates a passive state.  How about?:
>>
>> To ensure that an attacker cannot create a channel by obtaining key
>> exchanges between the client and KDC, it is desirable that neither the
>> KDC nor the client unilaterally determine the ticket session key.
> That still suggests a passive attacker to me.  I suggest:
>
> "To ensure that an active attacker cannot create separate channels to
> the client and KDC with the same known key, it is desirable that neither
> the KDC nor the client unilaterally determine the ticket session key."

I don't think "channels" is the right word in the updated sentence. I
interpreted the original text to indicate that an active attacker can
not snoop key exchanges between the client and KDC in order to
compromise a subsequent secure channel.

>>> "By requiring the session key in a way that..." is not grammatical.
>>>
>> How about?:
>>
>> This protocol binds the ticket to the DH exchange and prevents the MITM
>> attack by requiring the session key in a way that can be verified by the
>> client.
> I believe that change just reverses the two main clauses of the sentence
> without eliminating the grammar error.  You could say "requiring the
> session key to be created in a way...".

Sorry, was focused on the entire sentence.  Done.

Shawn.
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

Greg Hudson
On 08/24/2016 01:20 AM, Shawn M Emery wrote:

> On 08/17/16 09:58 AM, Greg Hudson wrote:
>> On 08/16/2016 12:12 AM, Shawn M Emery wrote:
>>>> In section 7, "To ensure that an attacker cannot create a channel
>>>> with a
>>>> given name" was changed to "To ensure that an attacker cannot create a
>>>> channel by observing exchanges."  The original wording may have used
>>>> "name" in a non-intuitive way, but I think the new wording is more
>>>> wrong.  The threat is that a MITM attacker might create two channels
>>>> with the same ticket session key (known to the attacker); the new
>>>> wording suggests that the threat comes from a passive attacker.
>>> Yes, the key word "observing" indicates a passive state.  How about?:
>>>
>>> To ensure that an attacker cannot create a channel by obtaining key
>>> exchanges between the client and KDC, it is desirable that neither the
>>> KDC nor the client unilaterally determine the ticket session key.
>> That still suggests a passive attacker to me.  I suggest:
>>
>> "To ensure that an active attacker cannot create separate channels to
>> the client and KDC with the same known key, it is desirable that neither
>> the KDC nor the client unilaterally determine the ticket session key."
>
> I don't think "channels" is the right word in the updated sentence. I
> interpreted the original text to indicate that an active attacker can
> not snoop key exchanges between the client and KDC in order to
> compromise a subsequent secure channel.

The attack being thwarted is described in the last paragraph of the section:

    A MITM attacker would just decrypt the session key + ticket using the
    DH key from the attacker and KDC DH exchange, and re-encrypt it using
    the key from the attacker and client DH exchange, while keeping a
    copy of the session key and ticket.

To add more detail: the scenario we are trying to protect is that a
client preauthenticates with unverified anonymous PKINIT to obtain a
TGT, then uses that TGT as FAST armor for encrypted challenge (or
another FAST factor with similar properties).  Without the mechanism in
section 7, an attacker in the middle could:

1. Perform its own anonymous PKINIT authentication to the real KDC to
get a ticket with a known session key.

2. Impersonate the KDC to the real client, performing the KDC side of
the anonymous PKINIT.

3. Issue a ticket to the client using the same session key as the one it
got in step 1.

4. Decrypt the subsequent FAST-protected AS exchange using the session
key from step 1.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten