Subject: RE: Updated I-Ds location Re: Extended One Week: WGLC GSS PRF and GSSKRB5 PRF drafts

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 2 May 2005 22:19:37 -0700

Here are some comments on the GSS-PRF draft.  

1. GSS_C_PRF_KEY_PARTIAL - you might want to mention that there should
only be one key specified as GSS_C_PRF_KEY_PARTIAL so that if a
mechanism happened to take a few round trips (perhaps contributing to
the complete key material) to complete you are sure that the call always
uses the same key value.  Ok this is mentioned at the end of the
section, you might re-organized this so it is discussed in the same
place. 

2. I think this is stated, but I want to make sure that if you call the
function on a context with the same parameters multiple times you get
the same results each time.  

3. In the security considerations, is there anything that can be said of
the keys generated from partial context after a context has completed?
In particular since mutual authentication has not happened at the time
the keys were generated is data protected under those keys valid if the
context complete successfully?

Is it worth mentioning that the in addition to forward protection that
the derived material from different inputs must be computationally
independent from one another and from any keys used for the GSS-WRAP and
GSS-MIC calls (i.e. so if you know the input and corresponding key
material that it is not computationally feasible to compute the material
for another input)?  It probably should also state that the
GSS_C_PRF_KEY_DEFAULT and GSS_C_PRF_KEY_PARTIAL MUST be derived from
secret key material and not just public data.  

4. In general I think this looks good for what might be useful in EAP.
When we were working on key derivation for EAP we broke the input data
into a part that was a standard tag that identified the purpose of the
key material and a part that was instance specific data.  This was to
prevent the same data from being used for two different key usages
resulting in a key collision.  This was important because it was
possible that one consumer of key material was unaware of what another
consumer was requesting.  It also provided a way to control access to
certain key material.  In GSS-API perhaps this is not a problem since
the consumers will in general be part of the same application/process
(although I suppose the context can be exported).  

5. We should probably chat a bit more about how this could fit with EAP
offline.  

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, April 28, 2005 2:01 PM
> To: Jeffrey Altman
> Cc: [email-masked]
> Subject: Updated I-Ds location Re: Extended One Week: WGLC 
> GSS PRF and GSSKRB5 PRF drafts
> 
> On Thu, Apr 28, 2005 at 09:09:30AM -0400, Jeffrey Altman wrote:
> > The working group last call on the two PRF related 
> documents is being 
> > extended until Thursday May 5th.  Yesterday there was extensive 
> > off-list discussion on the drafts among Nico Williams, Ken Raeburn, 
> > Tom Yu, and Jeffrey Hutzelman.  Nico has agreed to post new 
> versions 
> > of the drafts to a web site and summarize for the list the 
> discussions 
> > in order that consensus can be reached on the changes prior to 
> > submission to the Internet-Drafts editor.
> 
> http://blogs.sun.com/roller/resources/nico/kitten-gss-prf-03.txt
> http://blogs.sun.com/roller/resources/nico/kitten-krb5-gss-prf-03.txt
> 
> I'll generate some cleaned up diff output and post it.
> 
> Changes include:
> 
>  - I-D nits, typo fixes
> 
>  - addition of 'prf_key' key identifier to GSS_Pseudo_random(), to
>    support a PROT_READY-like feature and generic key identifier
>    constants, GSS_C_PRF_KEY_DEFAULT and GSS_C_PRF_KEY_PARTIAL
> 
>  - cleaned up text on minimum and minimum maximum input and 
> output data
>    sizes that must be supported
> 
> > I look forward to the rest of the working group being able 
> to review 
> > the work.
> 
> Me too.
> 
> Nico
> -- 
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/kitten
> 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 May 2005 00:34:53 -0500

> section, you might re-organized this so it is discussed in the same

I'll think about moving or re-organizing that text so that this
requirement can be found where prf_key is discussed.  But it's bloody
short text already... :)

> the same results each time.  

The last paragraph of section 2 of the -03 I put up on mediacast says:

                                            ...  Mechanisms that support
   GSS_C_PRF_KEY_PARTIAL MUST use the same PRF and key material, for any
   given security context and prf_key, both, before and after full
   context establishment, and the PRF and key material negotiation MUST
   be authenticated when the security context is fully established.

> context complete successfully?

The text above requires that upon full establishment the key material
used for GSS_C_PRF_KEY_PARTIAL must be authenticated.

I left out any verbiage about mutual authentication because that is
optional, but I thought that what is meant by "MUST be authenticated"
should be clear -- if not I can come up with additional text that does
make it clear.

> secret key material and not just public data.  

Agreed.  I'll work up some text.

> (although I suppose the context can be exported).  

Right.  Applications that pass exported contexts around should
coordinate what input they pass to GSS_Pseudo_random().

A convention of prefixing a usage tag to the input data can always be
applied by GSS applications if they may make multiple unrelated calls to
GSS_Pseudo_random().

Making such a usage tag an input parameter to the function doesn't
necessarily mean that proper use of it will be made, and because apps
can fashion one where necessary it seems like overkill to add such a
parameter.

The security considerations text already stresses the need to use
different input data for separate invocations on the same context.
Perhaps we should point out the "prepend a usage indicator" approach...

Alternatively we could add a per-call, per-context call counter that is
used as a usage indicator, but this would impose PRF call ordering on
the application, which seems like a bad idea.

> 5. We should probably chat a bit more about how this could fit with EAP

Yes.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 May 2005 13:14:59 -0500

> Agreed.  I'll work up some text.

I think the existing requirement that the function be a pseudo-random
function obtains the desired computational independence of GSS_PRF()
outputs for different inputs.

In the paragraph that reads:

   This function applies the established context's mechanism's keyed PRF
   function, using the desired key identified by 'prf_key', to the input
   data ('prf_in'), keyed with key material associated with the given
   security context and outputs the resulting octet string ('prf_out')
   of desired_output_len length.

I propose to change "...keyed with key material..." to "...keyed with
secret key material...," a rather trivial change :)

I propose the addition of "[the] PRF and/or its input key material must
be computationally independent from the keys and/or cryptographic
operations used by the mechanism for per-message tokens (MICs and
wraps)" at the end of the same paragraph.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 May 2005 16:40:05 -0400

These look reasonable as well.  I have not actually done an AD review
yet though.