Subject: [secdir] SECDIR Review of draft-ietf-dime-local-keytran-11.txt

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jul 2011 16:05:33 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.

SECURITY

There is no substantive security considerations, only a redirect to the
previous drafts.

This is somewhat problematic given that this is a document defining new
formats for key transport.

Minor

3.1.4.  Key-Lifetime AVP

The Key-Lifetime AVP (AVP Code <AC4>) is of type Unsigned32 and represents
the period of time (in seconds) for which the contents of the
Keying-Material AVP (Section 3.1.3) is valid.

If the key lifetime is really expected to be 2^32, i.e. 136 years then we
should probably expect quite a bit more mechanism here.

The delta encoding avoids millennium bug type problems (we.. maybe, it
probably just means that code will start to fail in 2032 or so when people
start specifying key lifetimes that cause signed 32 bit time to wrap.) but
it means that the start of the period is not fixed in time.

I think that at a minimum we need to have a security consideration pointing
out that there is an issue here. What happens if these messages are proxied
or cached in some fashion (OK it may not be in the protocol now, but can we
guarantee it never will be?)

Its probably not worth fixing since the protocols themselves are full of the
same issue but it should be called out as an SC.

-- 
Website: http://hallambaker.com/

---

From: Glen Zorn <[email-masked]>
Date: Fri, 15 Jul 2011 14:15:24 +0700

> formats for key transport.

If it is problematic then it would be quite helpful to say what exactly
the problem is.  Has the nature of cryptographic keys or Diameter
changed fundamentally since the publication of RFC 4072?  If not, what
is the problem?

> 
> 
> Minor
> 
> 3.1.4.  Key-Lifetime AVP
> 
> The Key-Lifetime AVP (AVP Code <AC4>) is of type Unsigned32 and
> represents the period of time (in seconds) for which the contents of the
> If the key lifetime is really expected to be 2^32, i.e. 136 years

They are most certainly not.

> then
> we should probably expect quite a bit more mechanism here.
> 
> probably just means that code will start to fail in 2032 or so when
> people start specifying key lifetimes that cause signed 32 bit time to
> wrap.) but it means that the start of the period is not fixed in time.
> 
> I think that at a minimum we need to have a security consideration
> pointing out that there is an issue here. What happens if these messages
> are proxied or cached in some fashion (OK it may not be in the protocol
> now, but can we guarantee it never will be?)
> 
> Its probably not worth fixing since the protocols themselves are full of
> the same issue but it should be called out as an SC.
> 
> 
> 
> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Jul 2011 21:41:02 -0400

> They are most certainly not.

Then maybe stating which parties might be expected to set limits and what
might be expected?

What happens if someone specifies a bizarrely long expiry on a credential
expected to expire in hours or days? Does that allow for an attack?

---

From: Glen Zorn <[email-masked]>
Date: Sun, 17 Jul 2011 17:49:32 +0700

On 7/17/2011 8:41 AM, Phillip Hallam-Baker wrote:
> On Fri, Jul 15, 2011 at 3:15 AM, Glen Zorn <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > Minor
>     >
>     > 3.1.4.  Key-Lifetime AVP
>     >
> Then maybe stating which parties might be expected to set limits and
> what might be expected?

Suggestions?  I'm inclined to believe that this sort of thing would be
better discussed in the documents defining the usage, derivation, etc.
of the keys themselves but I'm flexible.

> 
> What happens if someone specifies a bizarrely long expiry on a
> credential expected to expire in hours or days? Does that allow for an
> attack?

None I can think off-hand.  You?