LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

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

LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Jeffrey Hutzelman
At long last...

As of October 23, 2005, I am beginning a two-week Last Call period
on the following document:

        Title : Public Key Cryptography for
                          Initial Authentication in Kerberos
        Author(s) : B. Tung, L. Zhu
        Filename : draft-ietf-cat-kerberos-pk-init-29.txt
        Pages : 36
        Date : 2005-10-21

Comments on this document should be sent to the Kerberos Working Group
mailing list, [hidden email], and will be accepted at least until
11:59pm EST on November 6, 2005.  All issues raised will be entered
into the Request Tracker system at https://rt.psg.com/.


Once the Last Call period has ended, I will make a determination as to
whether there remain any unresolved issue, and whether there is a rough
consensus withing the working group to send this document to the IESG for
publication as a Proposed Standard.

-- Jeffrey T. Hutzelman (N3NHS) <[hidden email]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

Reply | Threaded
Open this post in threaded view
|

Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Tom Yu
Minor editorial nit:

pkinit> Interoperability note: Some implementations may not be able to
pkinit> decode wrapped CMS objects encoded with BER but not DER;
pkinit> specifically, they may not be able to decode infinite length
                                                     ^^^^^^^^
                                                     indefinite
pkinit> encodings.  To maximize interoperability, implementers SHOULD
pkinit> encode CMS objects used in PKINIT with DER.

I am still looking at the rest of it.

---Tom
Reply | Threaded
Open this post in threaded view
|

New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Jeffrey Altman
Here is proposed alternate introduction text for PKINIT:

1.  Introduction

   In its basic form, the Kerberos Network Authentication Service (V5)
   [RFC4120] Key Distribution Center (KDC) using symmetric cryptography
   issues Ticket Granting Tickets (TGTs) to clients encrypted with a
   secret key known to both the client and the KDC.  RFC4120
   further describes pre-authentication mechanisms that are based upon
   this shared secret or passwordless hardware authentication methods.

   The advantage afforded by the TGT is that the client exposes his
   long-term secrets only once.  The TGT and its associated session key
   can then be used for any subsequent service ticket requests.  One
   result of this is that all further authentication is independent of
   the method by which the initial authentication was performed.

   This document, Public Key Cryptography for Initial Authentication in
   Kerberos [PKINIT], defines a new pre-authentication method that uses
   public key cryptography for Kerberos initial ticket acquisition.
   This new method extends Kerberos to use credentials obtained from an
   established Public Key Infrastructure (PKI).

   There are several benefits obtained from integrating PKI and Kerberos
   as part of the Kerberos initial authentication.  Kerberos is the only
   authentication mechanism that supports single sign-on across multiple
   hosts and organizational authentication domains via use of delegation
   (ticket forwarding) and cross-realm.  PKINIT extends the use of PKI
   credentials to Kerberos infrastructure providing users with an
   enhanced single sign-on capability.

   The use of public key certificates instead of password based long
   term keys when performing the initial authentication increases the
   effort necessary to execute an offline attack on the client's long
   term secret.  Depending on the implementation it may also be possible
   to construct a dynamic process by which clients are registered with
   the KDC.

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

Re: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Jeffrey Altman
Here are the reasons I want to see new intro text:

 * the introduction should explain what this document achieves to a
   reader who is starting from 4120

 * the previous introduction is dervied from the text used when pkinit,
   pktap and pkcross were one document.   the text explaining why the
   initial ticket exchange is a convenient location to join PKI to
   kerberos is out of place without the rest of the text that was
   removed

 * the previous introduction describes the potential dynamic
   registration aspects of using certs which was a much more significant
   goal in the original combined pkinit, pktap, pkcross document

 * there needs to be better text explaining the delegation benefits of
   joining Kerberos and PKI for the PKI community.

I am sure the below text is not perfect but it was my first attempt at
a re-write.   I have received comments from Larry in private and I will
work to produce an improved second edition.

Jeffrey Altman



Jeffrey Altman wrote:

> Here is proposed alternate introduction text for PKINIT:
>
> 1.  Introduction
>
>    In its basic form, the Kerberos Network Authentication Service (V5)
>    [RFC4120] Key Distribution Center (KDC) using symmetric cryptography
>    issues Ticket Granting Tickets (TGTs) to clients encrypted with a
>    secret key known to both the client and the KDC.  RFC4120
>    further describes pre-authentication mechanisms that are based upon
>    this shared secret or passwordless hardware authentication methods.
>
>    The advantage afforded by the TGT is that the client exposes his
>    long-term secrets only once.  The TGT and its associated session key
>    can then be used for any subsequent service ticket requests.  One
>    result of this is that all further authentication is independent of
>    the method by which the initial authentication was performed.
>
>    This document, Public Key Cryptography for Initial Authentication in
>    Kerberos [PKINIT], defines a new pre-authentication method that uses
>    public key cryptography for Kerberos initial ticket acquisition.
>    This new method extends Kerberos to use credentials obtained from an
>    established Public Key Infrastructure (PKI).
>
>    There are several benefits obtained from integrating PKI and Kerberos
>    as part of the Kerberos initial authentication.  Kerberos is the only
>    authentication mechanism that supports single sign-on across multiple
>    hosts and organizational authentication domains via use of delegation
>    (ticket forwarding) and cross-realm.  PKINIT extends the use of PKI
>    credentials to Kerberos infrastructure providing users with an
>    enhanced single sign-on capability.
>
>    The use of public key certificates instead of password based long
>    term keys when performing the initial authentication increases the
>    effort necessary to execute an offline attack on the client's long
>    term secret.  Depending on the implementation it may also be possible
>    to construct a dynamic process by which clients are registered with
>    the KDC.



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

RE: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Larry Zhu
In reply to this post by Jeffrey Altman
I found the original text in -29 acceptable. I did not find the new text
as better.

Here are more detailed comments:

Jeffrey Altman wrote:
>
>    In its basic form, the Kerberos Network Authentication Service (V5)
>    [RFC4120] Key Distribution Center (KDC) using symmetric
cryptography
>    issues Ticket Granting Tickets (TGTs) to clients encrypted with a
>    secret key known to both the client and the KDC.  RFC4120
>    further describes pre-authentication mechanisms that are based upon
>    this shared secret or passwordless hardware authentication methods.
>

It seems to me that Kerberos does the same thing *when* PKINIT is used,
therefore, I think the wording "in its basic form" is awkward.

>    The advantage afforded by the TGT is that the client exposes his
>    long-term secrets only once.  The TGT and its associated session
key
>    can then be used for any subsequent service ticket requests.  One
>    result of this is that all further authentication is independent of
>    the method by which the initial authentication was performed.

I would suggest adding back the following text to the end of this
paragraph: "Consequently, initial authentication provides a convenient
place to integrate public-key cryptography into Kerberos
authentication."

Because that is the point being made, let's make it explicit.

Also I found the following text in -29 helpful, please do not drop that.

   As defined in [RFC4120], Kerberos authentication exchanges use
   symmetric-key cryptography, in part for performance.  One
   disadvantage of using symmetric-key cryptography is that the keys
   must be shared, so that before a client can authenticate itself, he
   must already be registered with the KDC.

This text suggests the trade-off of using PKINIT. It is helpful to point
out that symmetric-key cryptography does have a lot better performance.
And avoiding some form of the pre-registration is a significant
advantage of using PKI.


>    This document, Public Key Cryptography for Initial Authentication
in
>    Kerberos [PKINIT], defines a new pre-authentication method that
uses
>    public key cryptography for Kerberos initial ticket acquisition.

[lzhu] I prefer "initial authentication" over "initial ticket
acquisition".

>    This new method extends Kerberos to use credentials obtained from
an
>    established Public Key Infrastructure (PKI).

>    There are several benefits obtained from integrating PKI and
Kerberos
>    as part of the Kerberos initial authentication.  Kerberos is the
only
>    authentication mechanism that supports single sign-on across
multiple
>    hosts and organizational authentication domains via use of
delegation
>    (ticket forwarding) and cross-realm.  PKINIT extends the use of PKI
>    credentials to Kerberos infrastructure providing users with an
>    enhanced single sign-on capability.

[lzhu] this claim is controversial. I would also suggest that using
delegation is not the most significant advantage.  Listing it here is
misleading rather than convincing.

>    The use of public key certificates instead of password based long
>    term keys when performing the initial authentication increases the
>    effort necessary to execute an offline attack on the client's long
>    term secret.  Depending on the implementation it may also be
possible
>    to construct a dynamic process by which clients are registered with
>    the KDC.

[lzhu] this claim is controversial too. In addition, it is either too
generic or vague that I did not find it helpful when I read it.



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey Altman
Sent: Tuesday, November 08, 2005 8:24 AM
To: [hidden email]
Subject: Re: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

Here are the reasons I want to see new intro text:

 * the introduction should explain what this document achieves to a
   reader who is starting from 4120

 * the previous introduction is dervied from the text used when pkinit,
   pktap and pkcross were one document.   the text explaining why the
   initial ticket exchange is a convenient location to join PKI to
   kerberos is out of place without the rest of the text that was
   removed

 * the previous introduction describes the potential dynamic
   registration aspects of using certs which was a much more significant
   goal in the original combined pkinit, pktap, pkcross document

 * there needs to be better text explaining the delegation benefits of
   joining Kerberos and PKI for the PKI community.

I am sure the below text is not perfect but it was my first attempt at
a re-write.   I have received comments from Larry in private and I will
work to produce an improved second edition.

Jeffrey Altman



Jeffrey Altman wrote:
> Here is proposed alternate introduction text for PKINIT:
>
> 1.  Introduction
>
>    In its basic form, the Kerberos Network Authentication Service (V5)
>    [RFC4120] Key Distribution Center (KDC) using symmetric
cryptography
>    issues Ticket Granting Tickets (TGTs) to clients encrypted with a
>    secret key known to both the client and the KDC.  RFC4120
>    further describes pre-authentication mechanisms that are based upon
>    this shared secret or passwordless hardware authentication methods.
>
>    The advantage afforded by the TGT is that the client exposes his
>    long-term secrets only once.  The TGT and its associated session
key
>    can then be used for any subsequent service ticket requests.  One
>    result of this is that all further authentication is independent of
>    the method by which the initial authentication was performed.
>
>    This document, Public Key Cryptography for Initial Authentication
in
>    Kerberos [PKINIT], defines a new pre-authentication method that
uses
>    public key cryptography for Kerberos initial ticket acquisition.
>    This new method extends Kerberos to use credentials obtained from
an
>    established Public Key Infrastructure (PKI).
>
>    There are several benefits obtained from integrating PKI and
Kerberos
>    as part of the Kerberos initial authentication.  Kerberos is the
only
>    authentication mechanism that supports single sign-on across
multiple
>    hosts and organizational authentication domains via use of
delegation
>    (ticket forwarding) and cross-realm.  PKINIT extends the use of PKI
>    credentials to Kerberos infrastructure providing users with an
>    enhanced single sign-on capability.
>
>    The use of public key certificates instead of password based long
>    term keys when performing the initial authentication increases the
>    effort necessary to execute an offline attack on the client's long
>    term secret.  Depending on the implementation it may also be
possible
>    to construct a dynamic process by which clients are registered with
>    the KDC.
Reply | Threaded
Open this post in threaded view
|

RE: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Larry Zhu
In reply to this post by Jeffrey Altman
I have one more important point that I missed in my initial response.


Jeffrey Altman wrote:
>    This new method extends Kerberos to use credentials obtained from
an
>    established Public Key Infrastructure (PKI).

This is inaccurate. When the client mapping is based on the client's
public key, then there is no need for path-validation or PKI when using
PKINIT.

It is also possible to use raw public-private key pairs with PKINIT.


-----Original Message-----
From: Liqiang(Larry) Zhu
Sent: Tuesday, November 08, 2005 10:03 AM
To: 'Jeffrey Altman'; [hidden email]
Subject: RE: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

I found the original text in -29 acceptable. I did not find the new text
as better.

Here are more detailed comments:

Jeffrey Altman wrote:
>
>    In its basic form, the Kerberos Network Authentication Service (V5)
>    [RFC4120] Key Distribution Center (KDC) using symmetric
cryptography
>    issues Ticket Granting Tickets (TGTs) to clients encrypted with a
>    secret key known to both the client and the KDC.  RFC4120
>    further describes pre-authentication mechanisms that are based upon
>    this shared secret or passwordless hardware authentication methods.
>

It seems to me that Kerberos does the same thing *when* PKINIT is used,
therefore, I think the wording "in its basic form" is awkward.

>    The advantage afforded by the TGT is that the client exposes his
>    long-term secrets only once.  The TGT and its associated session
key
>    can then be used for any subsequent service ticket requests.  One
>    result of this is that all further authentication is independent of
>    the method by which the initial authentication was performed.

I would suggest adding back the following text to the end of this
paragraph: "Consequently, initial authentication provides a convenient
place to integrate public-key cryptography into Kerberos
authentication."

Because that is the point being made, let's make it explicit.

Also I found the following text in -29 helpful, please do not drop that.

   As defined in [RFC4120], Kerberos authentication exchanges use
   symmetric-key cryptography, in part for performance.  One
   disadvantage of using symmetric-key cryptography is that the keys
   must be shared, so that before a client can authenticate itself, he
   must already be registered with the KDC.

This text suggests the trade-off of using PKINIT. It is helpful to point
out that symmetric-key cryptography does have a lot better performance.
And avoiding some form of the pre-registration is a significant
advantage of using PKI.


>    This document, Public Key Cryptography for Initial Authentication
in
>    Kerberos [PKINIT], defines a new pre-authentication method that
uses
>    public key cryptography for Kerberos initial ticket acquisition.

[lzhu] I prefer "initial authentication" over "initial ticket
acquisition".

>    This new method extends Kerberos to use credentials obtained from
an
>    established Public Key Infrastructure (PKI).

>    There are several benefits obtained from integrating PKI and
Kerberos
>    as part of the Kerberos initial authentication.  Kerberos is the
only
>    authentication mechanism that supports single sign-on across
multiple
>    hosts and organizational authentication domains via use of
delegation
>    (ticket forwarding) and cross-realm.  PKINIT extends the use of PKI
>    credentials to Kerberos infrastructure providing users with an
>    enhanced single sign-on capability.

[lzhu] this claim is controversial. I would also suggest that using
delegation is not the most significant advantage.  Listing it here is
misleading rather than convincing.

>    The use of public key certificates instead of password based long
>    term keys when performing the initial authentication increases the
>    effort necessary to execute an offline attack on the client's long
>    term secret.  Depending on the implementation it may also be
possible
>    to construct a dynamic process by which clients are registered with
>    the KDC.

[lzhu] this claim is controversial too. In addition, it is either too
generic or vague that I did not find it helpful when I read it.



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey Altman
Sent: Tuesday, November 08, 2005 8:24 AM
To: [hidden email]
Subject: Re: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

Here are the reasons I want to see new intro text:

 * the introduction should explain what this document achieves to a
   reader who is starting from 4120

 * the previous introduction is dervied from the text used when pkinit,
   pktap and pkcross were one document.   the text explaining why the
   initial ticket exchange is a convenient location to join PKI to
   kerberos is out of place without the rest of the text that was
   removed

 * the previous introduction describes the potential dynamic
   registration aspects of using certs which was a much more significant
   goal in the original combined pkinit, pktap, pkcross document

 * there needs to be better text explaining the delegation benefits of
   joining Kerberos and PKI for the PKI community.

I am sure the below text is not perfect but it was my first attempt at
a re-write.   I have received comments from Larry in private and I will
work to produce an improved second edition.

Jeffrey Altman



Jeffrey Altman wrote:
> Here is proposed alternate introduction text for PKINIT:
>
> 1.  Introduction
>
>    In its basic form, the Kerberos Network Authentication Service (V5)
>    [RFC4120] Key Distribution Center (KDC) using symmetric
cryptography
>    issues Ticket Granting Tickets (TGTs) to clients encrypted with a
>    secret key known to both the client and the KDC.  RFC4120
>    further describes pre-authentication mechanisms that are based upon
>    this shared secret or passwordless hardware authentication methods.
>
>    The advantage afforded by the TGT is that the client exposes his
>    long-term secrets only once.  The TGT and its associated session
key
>    can then be used for any subsequent service ticket requests.  One
>    result of this is that all further authentication is independent of
>    the method by which the initial authentication was performed.
>
>    This document, Public Key Cryptography for Initial Authentication
in
>    Kerberos [PKINIT], defines a new pre-authentication method that
uses
>    public key cryptography for Kerberos initial ticket acquisition.
>    This new method extends Kerberos to use credentials obtained from
an
>    established Public Key Infrastructure (PKI).
>
>    There are several benefits obtained from integrating PKI and
Kerberos
>    as part of the Kerberos initial authentication.  Kerberos is the
only
>    authentication mechanism that supports single sign-on across
multiple
>    hosts and organizational authentication domains via use of
delegation
>    (ticket forwarding) and cross-realm.  PKINIT extends the use of PKI
>    credentials to Kerberos infrastructure providing users with an
>    enhanced single sign-on capability.
>
>    The use of public key certificates instead of password based long
>    term keys when performing the initial authentication increases the
>    effort necessary to execute an offline attack on the client's long
>    term secret.  Depending on the implementation it may also be
possible
>    to construct a dynamic process by which clients are registered with
>    the KDC.
Reply | Threaded
Open this post in threaded view
|

RE: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Chaskiel Grundman-3
In reply to this post by Larry Zhu
Note that I mostly agree with larry on the merits of the rewrite. In
particular, combining "single sign on" and delegation doesn't make sense to
me. delegation is credential pass through, not single sign on. (There is
nothing about pk that prevents it from being used as an SSO mechanism.)

--On Tuesday, November 08, 2005 10:02:56 -0800 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

>Jeffrey Altman wrote:
>>One
>> disadvantage of using symmetric-key cryptography is that the keys
>> must be shared, so that before a client can authenticate itself, he
>> must already be registered with the KDC.
> avoiding some form of the pre-registration is a significant
> advantage of using PKI.
>>    The use of public key certificates instead of password based long
>>    term keys when performing the initial authentication increases the
>>    effort necessary to execute an offline attack on the client's long
>>    term secret.  Depending on the implementation it may also be
> possible
>>    to construct a dynamic process by which clients are registered with
>>    the KDC.
> [lzhu] this claim is controversial too. In addition, it is either too
> generic or vague that I did not find it helpful when I read it.

Which claim is controversial? if you are referring to the "dynamic
process...", isn't that the same thing that avoids "some form of
pre-registration" that you earlier indicated is a good idea?
(I don't think it is controversial to claim that a randomly-generated
public key is harder to attack than a key derived from a password provided
by the user.)


attachment0 (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Larry Zhu
In reply to this post by Jeffrey Altman
>> Jeff wrote:
>> initial authentication increases the
>>    effort necessary to execute an offline attack on the client's long
>>    term secret.  

Chaskiel M Grundman wrote:
> Which claim is controversial? if you are referring to the "dynamic
> process...",

I referred to the claim "...increases the effort necessary to execute an
offline attack on the client's long term secret". I do not claim right
away this is incorrect, it is just not clear to me.

I do understand that here at Redmond, we refer to the client's
public-private key pairs as "long term secrets" as well.

I think it is misleading to say if you use PKINIT, you increase the
attacker's effort, you might not.

This is because it all depends on the size of the key, for example a 256
bit AES key is not easier to crack than a 1024 bit RSA key pair, and I
just do not find the text helpful.

If we want to convince someone to implement/adopt PKINIT with this text,
it is not sufficient then. Hypothetically if this protocol makes the
attacker's life just twice as harder, I would not be convinced.

Does this make sense?



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Chaskiel M
Grundman
Sent: Tuesday, November 08, 2005 10:39 AM
To: [hidden email]
Subject: RE: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

Note that I mostly agree with larry on the merits of the rewrite. In
particular, combining "single sign on" and delegation doesn't make sense
to
me. delegation is credential pass through, not single sign on. (There is

nothing about pk that prevents it from being used as an SSO mechanism.)

--On Tuesday, November 08, 2005 10:02:56 -0800 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

>Jeffrey Altman wrote:
>>One
>> disadvantage of using symmetric-key cryptography is that the keys
>> must be shared, so that before a client can authenticate itself, he
>> must already be registered with the KDC.
> avoiding some form of the pre-registration is a significant
> advantage of using PKI.
>>    The use of public key certificates instead of password based long
>>    term keys when performing the initial authentication increases the
>>    effort necessary to execute an offline attack on the client's long
>>    term secret.  Depending on the implementation it may also be
> possible
>>    to construct a dynamic process by which clients are registered
with
>>    the KDC.
> [lzhu] this claim is controversial too. In addition, it is either too
> generic or vague that I did not find it helpful when I read it.


Which claim is controversial? if you are referring to the "dynamic
process...", isn't that the same thing that avoids "some form of
pre-registration" that you earlier indicated is a good idea?
(I don't think it is controversial to claim that a randomly-generated
public key is harder to attack than a key derived from a password
provided
by the user.)
Reply | Threaded
Open this post in threaded view
|

Re: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Brian Tung
Liqiang(Larry) Zhu wrote:
> This is because it all depends on the size of the key, for example a 256
> bit AES key is not easier to crack than a 1024 bit RSA key pair, and I
> just do not find the text helpful.

It is easier if the 256-bit AES key is password-derived.  That is a
common case with vanilla Kerberos.

> If we want to convince someone to implement/adopt PKINIT with this text,
> it is not sufficient then. Hypothetically if this protocol makes the
> attacker's life just twice as harder, I would not be convinced.

If the difference is between password-derived key and randomly-generated
public key pair, the difference is much more than a factor of two.

--
Brian Tung <[hidden email]>
* etiam non me contradixisti * et cuniculi et vulpeculae moriuntur *
USC Information Sciences Institute

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: New Intro Text was Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

Larry Zhu
In reply to this post by Jeffrey Altman


I agree with Chaskiel M Grundman and you that it is more secure to use a
randomly-generated long public-private key pair than a weak password.
And users typically can not remember strong passwords; therefore it is
beneficial to use PKINIT for initial authentication.

This seems to be helpful/useful, I would not object adding this to the
existing text in -29.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Brian Tung
Sent: Tuesday, November 08, 2005 11:33 AM
To: [hidden email]
Subject: Re: New Intro Text was Re: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos

Liqiang(Larry) Zhu wrote:
> This is because it all depends on the size of the key, for example a
256
> bit AES key is not easier to crack than a 1024 bit RSA key pair, and I
> just do not find the text helpful.

It is easier if the 256-bit AES key is password-derived.  That is a
common case with vanilla Kerberos.

> If we want to convince someone to implement/adopt PKINIT with this
text,
> it is not sufficient then. Hypothetically if this protocol makes the
> attacker's life just twice as harder, I would not be convinced.

If the difference is between password-derived key and randomly-generated
public key pair, the difference is much more than a factor of two.

--
Brian Tung <[hidden email]>
* etiam non me contradixisti * et cuniculi et vulpeculae moriuntur *
USC Information Sciences Institute
Reply | Threaded
Open this post in threaded view
|

TD-DH-PARAMETERS (Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos)

Tom Yu
In reply to this post by Jeffrey Hutzelman
Regarding to Love's comment in the WG session, I have examined Section
3.2.2 of pkinit-29 and found that TD-DH-PARAMETERS is in fact
underspecified.  AlgorithmIdentifier is basically a typed hole, with
the contents being an ASN.1 type identified with an OID.  Section
3.2.2 does not specify what OID or ASN.1 type to use in
TD-DH-PARAMETERS.  I have looked at the the referenced standard, IEEE
1363, which does not itself specify any OIDs or ASN.1 types as far as
I can tell.  IEEE 1363 only really specifies the math behind using
DH.

What is probably meant is the OID and ASN.1 type in RFC 3279
associated with Diffie-Hellman domain parameters, which is in turn
based on ANSI X9.42 (which I don't think I have access to).

---Tom
Reply | Threaded
Open this post in threaded view
|

RE: TD-DH-PARAMETERS (Re: LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos)

Larry Zhu
Love and I have resolved this issue. I requested Love to propose the
text to the list and he already did.

If no one objects to his proposal (see his latest posting), his text
shall be folded to -30, and -30 will be forwarded to IESG.

Thanks,

-- larry

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Tom Yu
Sent: Tuesday, November 08, 2005 2:15 PM
To: Jeffrey Hutzelman
Cc: [hidden email]
Subject: TD-DH-PARAMETERS (Re: LAST CALL - Public Key Cryptography for
Initial Authentication in Kerberos)

Regarding to Love's comment in the WG session, I have examined Section
3.2.2 of pkinit-29 and found that TD-DH-PARAMETERS is in fact
underspecified.  AlgorithmIdentifier is basically a typed hole, with
the contents being an ASN.1 type identified with an OID.  Section
3.2.2 does not specify what OID or ASN.1 type to use in
TD-DH-PARAMETERS.  I have looked at the the referenced standard, IEEE
1363, which does not itself specify any OIDs or ASN.1 types as far as
I can tell.  IEEE 1363 only really specifies the math behind using
DH.

What is probably meant is the OID and ASN.1 type in RFC 3279
associated with Diffie-Hellman domain parameters, which is in turn
based on ANSI X9.42 (which I don't think I have access to).

---Tom