headers
Shawn M Emery | 2 Apr 2007 09:15
Picon

draft-ietf-krb-wg-pkinit-alg-agility-02 review


Here is my review of draft-ietf-krb-wg-pkinit-alg-agility-02:

Overall:
This is improved from the previous revision that I read.  Thanks.

Abstract:
Replace SHA with SHA-1

Introduction:
Add RFC reference to "... 3.2.3 of [RFC4556] ..."

Are there any length limits for the Introductions?

Don't nonces in the protocol negate the affect of potential collisions?

6. KDF agility

New update drafts have to be created as new KDFs become available?

nit: "cryptographic bindings" should be "cryptographic binding"
nit: "thus addresses" should be "thus addressing"

Why are the "...," strings defined?

What if the id request is disjoint from the supported list by the server?

Why is pkinit-kdf-ah-sha256 the limiting algorithm?

7. Security Considerations
(Continue reading)

Permalink | Reply | 1 comment |
headers
Liqiang(Larry) Zhu | 5 Apr 2007 09:44
Picon
Favicon

RE: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

On page 3 of RFC4121, we have the following text:

   The term "little-endian order" is used for brevity to refer to the
   least-significant-octet-first encoding, while the term "big-endian
   order" is for the most-significant-octet-first encoding.

Because this document updates RFC4121, we should be covered here if we
just stick with using the big-endian order idom.

--larry

-----Original Message-----
From: Martin Rex [mailto:martin.rex <at> sap.com] 
Sent: Tuesday, March 27, 2007 3:25 PM
To: Shawn M Emery
Cc: martin.rex <at> sap.com; jhutz <at> cmu.edu; Liqiang(Larry) Zhu;
ietf-krb-wg <at> anl.gov
Subject: Re: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

Shawn M Emery wrote:
> 
> Earlier in the document, it defines "big endian order" as "the 
> most-significant-octet-first encoding".
> I should be sufficient. The next revision of the draft will use "big 
> endian order", instead
> of "network-byte order".  I think that this was the only issue so far 
> with revision 1 of the document?

I really want to see the terms "big endian" and "network-byte order"
removed entirely from the document and only an expression like
(Continue reading)

Permalink | Reply | 4 comments |
headers
Marcus Watts | 5 Apr 2007 11:24
Picon

Re: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

"Liqiang(Larry) Zhu" <lzhu <at> windows.microsoft.com> sent:
> On page 3 of RFC4121, we have the following text:
> 
>    The term "little-endian order" is used for brevity to refer to the
>    least-significant-octet-first encoding, while the term "big-endian
>    order" is for the most-significant-octet-first encoding.
> 
> Because this document updates RFC4121, we should be covered here if we
> just stick with using the big-endian order idom.
> 
> --larry
> 
> -----Original Message-----
> From: Martin Rex [mailto:martin.rex <at> sap.com]=20
> Sent: Tuesday, March 27, 2007 3:25 PM
> To: Shawn M Emery
> Cc: martin.rex <at> sap.com; jhutz <at> cmu.edu; Liqiang(Larry) Zhu;
> ietf-krb-wg <at> anl.gov
> Subject: Re: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt
> 
> Shawn M Emery wrote:
> >=20
> > Earlier in the document, it defines "big endian order" as "the=20
> > most-significant-octet-first encoding".
> > I should be sufficient. The next revision of the draft will use "big=20
> > endian order", instead
> > of "network-byte order".  I think that this was the only issue so far=20
> > with revision 1 of the document?
> 
> I really want to see the terms "big endian" and "network-byte order"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kevin Coffman | 5 Apr 2007 15:40
Picon
Favicon

Fwd: WGLC comments on draft-ietf-krb-wg-naming-03.txt

[Resending after re- re-subscribing...]

The heading lists the "NETWORK WORKING GROUP".  I see that rfc4120 was
published with the same thing, but shouldn't this be the "Kerberos
Working Group"?

There is a typo in the Abstract ("principal name" s/b "principal
names"), but Jeffrey's suggested rephrasing handles that.

Section 3.1 (and repeated in Section 3.2) has another typo:

   "and SHOULD reject the authentication attempt is a
   well-known principal name is used ..."

That should read "if a well-known..."

Also in Section 3.1 (and repeated in Section 3.2), I was confused by
the sentence, "Unless otherwise specified, if a well-known
[principal|realm] name is used but not supported in any other places
of Kerberos messages, authentication MUST fail".

I suggest rephrasing this to, "Unless otherwise specified, if a
well-known [principal|realm] name is used in any other Kerberos
message, but is not supported, authentication MUST fail."

K.C.
Permalink | Reply | 5 comments |
headers
Kevin Coffman | 5 Apr 2007 16:11
Picon
Favicon

WGLC comments on draft-ietf-krb-wg-naming-03.txt

Trying once again (sorry for any duplicates...)

The heading lists the "NETWORK WORKING GROUP".  I see that rfc4120 was 
published with the same thing, but shouldn't this be the "Kerberos 
Working Group"?

There is a typo in the Abstract ("principal name" s/b "principal 
names"), but Jeffrey's suggested rephrasing handles that.

Section 3.1 (and repeated in Section 3.2) has another typo:

   "and SHOULD reject the authentication attempt
   is a well-known principal name is used ..."

That should read "if a well-known..."

Also in Section 3.1 (and repeated in Section 3.2), I was confused by 
the sentence, "Unless otherwise specified, if a well-known 
[principal|realm] name is used but not supported in any other places of 
Kerberos messages, authentication MUST fail".

I suggest rephrasing this to, "Unless otherwise specified, if a 
well-known [principal|realm] name is used in any other Kerberos 
message, but is not supported, authentication MUST fail."

K.C.
Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 5 Apr 2007 17:49
Picon
Favicon

Re: Fwd: WGLC comments on draft-ietf-krb-wg-naming-03.txt


On Thursday, April 05, 2007 09:40:04 AM -0400 Kevin Coffman 
<kwc <at> citi.umich.edu> wrote:

> [Resending after re- re-subscribing...]
>
>
> The heading lists the "NETWORK WORKING GROUP".  I see that rfc4120 was
> published with the same thing, but shouldn't this be the "Kerberos
> Working Group"?

No; the heading is correct.  See <http://rfc-editor.org/rfcfaq.html#wg>

> Also in Section 3.1 (and repeated in Section 3.2), I was confused by
> the sentence, "Unless otherwise specified, if a well-known
> [principal|realm] name is used but not supported in any other places
> of Kerberos messages, authentication MUST fail".
>
> I suggest rephrasing this to, "Unless otherwise specified, if a
> well-known [principal|realm] name is used in any other Kerberos
> message, but is not supported, authentication MUST fail."

The existing text does not just refer to other messages; it also covers 
other fields in the messages that are discussed.  I agree the sentence in 
question should be reworded, but I don't think your suggested phrasing 
captures this distinction.

-- Jeff
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kevin Coffman | 5 Apr 2007 18:31
Picon
Favicon

Re: Fwd: WGLC comments on draft-ietf-krb-wg-naming-03.txt

On 4/5/07, Jeffrey Hutzelman <jhutz <at> cmu.edu> wrote:
>
> On Thursday, April 05, 2007 09:40:04 AM -0400 Kevin Coffman
> <kwc <at> citi.umich.edu> wrote:
>
> > Also in Section 3.1 (and repeated in Section 3.2), I was confused by
> > the sentence, "Unless otherwise specified, if a well-known
> > [principal|realm] name is used but not supported in any other places
> > of Kerberos messages, authentication MUST fail".
> >
> > I suggest rephrasing this to, "Unless otherwise specified, if a
> > well-known [principal|realm] name is used in any other Kerberos
> > message, but is not supported, authentication MUST fail."
>
> The existing text does not just refer to other messages; it also covers
> other fields in the messages that are discussed.  I agree the sentence in
> question should be reworded, but I don't think your suggested phrasing
> captures this distinction.
>
> -- Jeff

OK, is either of these any better?

"If a well-known [principal|realm] name is used in any other field of
any other Kerberos message where its use is not explicitly specified,
authentication MUST fail."

"Unless support is specified elsewhere, if a well-known
[principal|realm] name appears in any other field of any other
Kerberos message, authentication MUST fail."
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeffrey Hutzelman | 5 Apr 2007 18:38
Picon
Favicon

Re: Fwd: WGLC comments on draft-ietf-krb-wg-naming-03.txt


On Thursday, April 05, 2007 12:31:23 PM -0400 Kevin Coffman 
<kwc <at> citi.umich.edu> wrote:

> "If a well-known [principal|realm] name is used in any other field of
> any other Kerberos message where its use is not explicitly specified,
> authentication MUST fail."
>
> "Unless support is specified elsewhere, if a well-known
> [principal|realm] name appears in any other field of any other
> Kerberos message, authentication MUST fail."

Change "any other Kerberos message" to "any Kerberos message" (in two 
places), and I think we've got it.  Comments, anyone?
Permalink | Reply | 2 comments |
headers
Jeffrey Hutzelman | 5 Apr 2007 18:40
Picon
Favicon

Re: Fwd: WGLC comments on draft-ietf-krb-wg-naming-03.txt


On Thursday, April 05, 2007 12:38:51 PM -0400 Jeffrey Hutzelman 
<jhutz <at> cmu.edu> wrote:

>
>
> On Thursday, April 05, 2007 12:31:23 PM -0400 Kevin Coffman
> <kwc <at> citi.umich.edu> wrote:
>
>> "If a well-known [principal|realm] name is used in any other field of
>> any other Kerberos message where its use is not explicitly specified,
>> authentication MUST fail."
>>
>> "Unless support is specified elsewhere, if a well-known
>> [principal|realm] name appears in any other field of any other
>> Kerberos message, authentication MUST fail."
>
>
> Change "any other Kerberos message" to "any Kerberos message" (in two
> places), and I think we've got it.  Comments, anyone?

<sigh>; I was not reading carefully enough to notice that you were 
proposing two alternatives.  With the change, I'm fine with either one, 
with a very slight preference for the first.

I would like to hear from others on whether this is OK.

-- Jeff
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nicolas Williams | 5 Apr 2007 18:57
Picon

Re: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

I'm with Larry here.  RFCs 1964 and 4121 used 'little-endian' and
'big-endian', so it seems natural that any updates to them should stick
to terminology that was in use in those RFCs.

Marcus' analysis of the RFC series' use of these and other terms, and of
the history of some of these terms is fascinating.  Thanks for taking
the time to look at that.

Finally, RFC4121 actually has a paragraph, that this I-D repeats,
defining big- and little-endian:

   The term "little-endian order" is used for brevity to refer to the
   least-significant-octet-first encoding, while the term "big-endian
   order" is for the most-significant-octet-first encoding.

which should be more than sufficient...

...unless we take Marcus' note about 'octet' being confusing seriously,
in which case we'll have to use 'byte' or else add a definition of
'octet' :)

So, count me as being in favor of leaving draft-ietf-krb-wg-gss-cb-
hash-agility-01.txt alone on this matter.

Have we spilled enough bandwidth on this topic now?

Of course, this tangent was worth it, since IEN137 is worth reading and
re-reading every so often...

Nico
(Continue reading)

Permalink | Reply | 2 comments |

Gmane