Last Call Review of draft-ietf-dime-local-keytran-
review-ietf-dime-local-keytran-secdir-lc-hallam-baker-2011-08-01-00

Request Review of draft-ietf-dime-local-keytran
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-07-12
Requested 2011-05-31
Authors Glen Zorn, Qin Wu, Violeta Cakulev
Draft last updated 2011-08-01
Completed reviews Secdir Last Call review of -?? by Phillip Hallam-Baker
Assignment Reviewer Phillip Hallam-Baker 
State Completed
Review review-ietf-dime-local-keytran-secdir-lc-hallam-baker-2011-08-01
Review completed: 2011-08-01

Review
review-ietf-dime-local-keytran-secdir-lc-hallam-baker-2011-08-01

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/