Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

[Michiko Short]

Ok, since answer not obvious starting thread on Kitten. 

-Original Message-
From: Jari Arkko [mailto:jari.ar...@piuha.net] 
Sent: Thursday, December 1, 2016 1:30 AM
To: Benjamin Kaduk 
Cc: Paul Miller (NT) ; Michiko Short 
; IETF Gen-ART ; 
draft-ietf-kitten-pkinit-freshness@ietf.org
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Many thanks for your review, Russ, and for thinking about this space and what 
issues there might be.

I too am concerned about the issue that Russ Housley raised: bad practices in 
creating the freshness tokens creates a security issue. If this cannot be 
handled in the way that Russ initially suggested (setting a minimum number of 
bits) then a proper discussion of the issue and recommendations to avoid the 
problems need to be included in the security considerations section.

I fully recognise the point from the authors that different styles of creating 
the tokens result in different implications, and that setting a mere minimum 
number of bits may not be appropriate.

Jari

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

[Jari Arkko]

Many thanks for your review, Russ, and for thinking about this space and what 
issues there might be.

I too am concerned about the issue that Russ Housley raised: bad practices in 
creating the freshness tokens creates a security issue. If this cannot be 
handled in the way that Russ initially suggested (setting a minimum number of 
bits) then a proper discussion of the issue and recommendations to avoid the 
problems need to be included in the security considerations section.

I fully recognise the point from the authors that different styles of creating 
the tokens result in different implications, and that setting a mere minimum 
number of bits may not be appropriate.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

[Benjamin Kaduk]

On Mon, Nov 28, 2016 at 09:53:35PM +, Paul Miller (NT) wrote:
> Minimum length is a problematic topic due to the fact that we intentionally 
> did not specify the format of the freshness token.  Since the structure of 
> the freshness token is left up to the KDC, there is no good way to determine 
> a minimum size.  If the freshness token is a nonce then the size is 
> determined by the birthday problem.  If it is based on symmetric 
> cryptography, then there are different length considerations.  If it is based 
> on asymmetric crypto then there is a third set of size considerations.

We could still mention in the security considerations that depending on the
construction of the token, the token should have some minimum size; essentially,
your text from above.

-Ben

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

[Michiko Short]

Russ, is there an accepted value for a worst case CMS signature?

-Original Message-
From: Paul Miller (NT) 
Sent: Monday, November 28, 2016 1:54 PM
To: Michiko Short ; Russ Housley 
; draft-ietf-kitten-pkinit-freshness@ietf.org
Cc: IETF Gen-ART 
Subject: RE: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Minimum length is a problematic topic due to the fact that we intentionally did 
not specify the format of the freshness token.  Since the structure of the 
freshness token is left up to the KDC, there is no good way to determine a 
minimum size.  If the freshness token is a nonce then the size is determined by 
the birthday problem.  If it is based on symmetric cryptography, then there are 
different length considerations.  If it is based on asymmetric crypto then 
there is a third set of size considerations.

A maximum size makes sense as a way to avoid processing messages that are 
clearly bad.  Is there an accepted value for a worst case CMS signature?

-Original Message-
From: Michiko Short [mailto:michi...@microsoft.com] 
Sent: Monday, November 28, 2016 8:59 AM
To: Russ Housley ; 
draft-ietf-kitten-pkinit-freshness@ietf.org
Cc: IETF Gen-ART 
Subject: RE: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

The size issue a is big one for this late in the process as it never came up 
before. We would have to bring it up to the WG for discussion. Is this 
required? 

Happy to submit an updated version with the client & KDC flipped, first 
reference of KDC in abstract spelled out, and 2.1 PA_AS_FRESHNESS referencing 
4. Just tell me when I can make the updates.

-Original Message-
From: Russ Housley [mailto:hous...@vigilsec.com] 
Sent: Sunday, November 27, 2016 11:55 AM
To: draft-ietf-kitten-pkinit-freshness@ietf.org
Cc: IETF Gen-ART 
Subject: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at 
.

Document: draft-ietf-kitten-pkinit-freshness-07
Reviewer: Russ Housley
Review Date: 2016-11-27
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-12-01

Summary: Almost Ready

Major Concerns

I understand that freshness tokens provide corroboration that the client had 
access to the private key at the time that the AS-REQ was constructed.  I also 
understand that the freshness tokens do not have to be single use tokens for 
specific AS exchanges.  However, some guidance on the minimum size of the 
freshness token seems to be appropriate.  If the freshness token is too small, 
then the client could be generate signatures using all of the possible token 
values at when it does have access to the private key, offering the one that 
matches the freshness token during the exchange with the KDC.  Please specify a 
minimum size for the freshness token.

Please add a discussion of the minimum freshness token size to Section 7 
(Security Considerations).

Question: Is there a reson to specify a maximum size for the freshness token?  
If an implementor knows that the freshness token will be under some maximum, 
then the code can incorporate that information into the buffer management and 
easily discard any KRB-ERROR messages that exceed that maximum.


Minor Concerns

In the Abstract and Section 1 (Introduction), please spell out KDC the first 
time the acronym is used.

In Section 2.2 (Generation of KRB_ERROR Message), please give the reader a 
heads up that PA_AS_FRESHNESS is defined in this document.  I went looking for 
it in RFC 4120; a pointer could have avoided this wild goose chase.


Nits

In Figure 1, since the client begins the conversation, it would read better if 
the Client were on the left side of the figure.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

[Paul Miller (NT)]

Minimum length is a problematic topic due to the fact that we intentionally did 
not specify the format of the freshness token.  Since the structure of the 
freshness token is left up to the KDC, there is no good way to determine a 
minimum size.  If the freshness token is a nonce then the size is determined by 
the birthday problem.  If it is based on symmetric cryptography, then there are 
different length considerations.  If it is based on asymmetric crypto then 
there is a third set of size considerations.

A maximum size makes sense as a way to avoid processing messages that are 
clearly bad.  Is there an accepted value for a worst case CMS signature?

-Original Message-
From: Michiko Short [mailto:michi...@microsoft.com] 
Sent: Monday, November 28, 2016 8:59 AM
To: Russ Housley ; 
draft-ietf-kitten-pkinit-freshness@ietf.org
Cc: IETF Gen-ART 
Subject: RE: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

The size issue a is big one for this late in the process as it never came up 
before. We would have to bring it up to the WG for discussion. Is this 
required? 

Happy to submit an updated version with the client & KDC flipped, first 
reference of KDC in abstract spelled out, and 2.1 PA_AS_FRESHNESS referencing 
4. Just tell me when I can make the updates.

-Original Message-
From: Russ Housley [mailto:hous...@vigilsec.com] 
Sent: Sunday, November 27, 2016 11:55 AM
To: draft-ietf-kitten-pkinit-freshness@ietf.org
Cc: IETF Gen-ART 
Subject: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at 
.

Document: draft-ietf-kitten-pkinit-freshness-07
Reviewer: Russ Housley
Review Date: 2016-11-27
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-12-01

Summary: Almost Ready

Major Concerns

I understand that freshness tokens provide corroboration that the client had 
access to the private key at the time that the AS-REQ was constructed.  I also 
understand that the freshness tokens do not have to be single use tokens for 
specific AS exchanges.  However, some guidance on the minimum size of the 
freshness token seems to be appropriate.  If the freshness token is too small, 
then the client could be generate signatures using all of the possible token 
values at when it does have access to the private key, offering the one that 
matches the freshness token during the exchange with the KDC.  Please specify a 
minimum size for the freshness token.

Please add a discussion of the minimum freshness token size to Section 7 
(Security Considerations).

Question: Is there a reson to specify a maximum size for the freshness token?  
If an implementor knows that the freshness token will be under some maximum, 
then the code can incorporate that information into the buffer management and 
easily discard any KRB-ERROR messages that exceed that maximum.


Minor Concerns

In the Abstract and Section 1 (Introduction), please spell out KDC the first 
time the acronym is used.

In Section 2.2 (Generation of KRB_ERROR Message), please give the reader a 
heads up that PA_AS_FRESHNESS is defined in this document.  I went looking for 
it in RFC 4120; a pointer could have avoided this wild goose chase.


Nits

In Figure 1, since the client begins the conversation, it would read better if 
the Client were on the left side of the figure.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

[Michiko Short]

The size issue a is big one for this late in the process as it never came up 
before. We would have to bring it up to the WG for discussion. Is this 
required? 

Happy to submit an updated version with the client & KDC flipped, first 
reference of KDC in abstract spelled out, and 2.1 PA_AS_FRESHNESS referencing 
4. Just tell me when I can make the updates.

-Original Message-
From: Russ Housley [mailto:hous...@vigilsec.com] 
Sent: Sunday, November 27, 2016 11:55 AM
To: draft-ietf-kitten-pkinit-freshness@ietf.org
Cc: IETF Gen-ART 
Subject: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at 
.

Document: draft-ietf-kitten-pkinit-freshness-07
Reviewer: Russ Housley
Review Date: 2016-11-27
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-12-01

Summary: Almost Ready

Major Concerns

I understand that freshness tokens provide corroboration that the client had 
access to the private key at the time that the AS-REQ was constructed.  I also 
understand that the freshness tokens do not have to be single use tokens for 
specific AS exchanges.  However, some guidance on the minimum size of the 
freshness token seems to be appropriate.  If the freshness token is too small, 
then the client could be generate signatures using all of the possible token 
values at when it does have access to the private key, offering the one that 
matches the freshness token during the exchange with the KDC.  Please specify a 
minimum size for the freshness token.

Please add a discussion of the minimum freshness token size to Section 7 
(Security Considerations).

Question: Is there a reson to specify a maximum size for the freshness token?  
If an implementor knows that the freshness token will be under some maximum, 
then the code can incorporate that information into the buffer management and 
easily discard any KRB-ERROR messages that exceed that maximum.


Minor Concerns

In the Abstract and Section 1 (Introduction), please spell out KDC the first 
time the acronym is used.

In Section 2.2 (Generation of KRB_ERROR Message), please give the reader a 
heads up that PA_AS_FRESHNESS is defined in this document.  I went looking for 
it in RFC 4120; a pointer could have avoided this wild goose chase.


Nits

In Figure 1, since the client begins the conversation, it would read better if 
the Client were on the left side of the figure.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art