[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ticket and SA lifetime (Re: kink-09)
- To: Kazunori Miyazawa <kazunori@xxxxxxxxxxxx>
- Subject: Re: Ticket and SA lifetime (Re: kink-09)
- From: Michael Thomas <mat@xxxxxxxxx>
- Date: Fri, 30 Sep 2005 08:21:49 -0700
- Authentication-results: imail.cisco.com; header.Fromemail@example.com; dkim=pass ( message from cisco.com verified; );
- Cc: "KAMADA Ken'ichi" <kamada@xxxxxxxxxx>, ietf-kink@xxxxxxxx
- Dkim-signature: a=rsa-sha1; q=dns; l=2783; t=1128094393; x=1128526593; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; firstname.lastname@example.org; z=Subject:Re=3A=20Ticket=20and=20SA=20lifetime=20(Re=3A=20kink-09)| From:Michael=20Thomas=20<email@example.com>| Date:Fri,=2030=20Sep=202005=2008=3A21=3A49=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=XSIwqcW+H/lzdFivGVt53lzp+zff9UU6A2cKxC1Wr4lz0Ktfh6f/Oq1c+3qBrKARyKxLqbbr JvaZedt/SQmLW3Ucz1QIYzL5cnhNNyFE6+P+vuNUavJ+YzC6vy4ZMG6wff4GPjNboLpWPtqq8kz vRB1EG3yNDtHsTE8RUnrNE6U=
- In-reply-to: <>
- List-archive: <http://www.vpnc.org/ietf-kink/mail-archive/>
- List-id: <ietf-kink.vpnc.org>
- List-unsubscribe: <mailto:firstname.lastname@example.org?body=unsubscribe>
- References: <> <> <>
- Sender: owner-ietf-kink@xxxxxxxxxxxxx
- User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0
What I'd appreciate here is some insight as to what other
Kerberized applications do, especially ones that have their
own session timers. If they all mimimize their lifetimes to
the extant of the kerberos ticket lifetime, then that pretty
much tells us we should too. If some are independant, then I
think it's probably a local policy decision of the receiver
assuming that the ISAKMP negotiation allows a longer proposed
lifetime to be shortened by the receiver. If that's the case,
then I don't think that the spec needs to recommend anything,
and if it does it should at most be a SHOULD.
Kazunori Miyazawa wrote:
KAMADA Ken'ichi wrote:
At Wed, 7 Sep 2005 15:08:29 -0400,
Ken Raeburn <raeburn@xxxxxxx> wrote:
Relatively minor stuff:
- Section 3.6: One case that might be worth mentioning is when the
user's tickets are going to expire at the end of the "hard lifetime
by time" of the SA. In that case, unless there's some other reason
(lifetime by byte count?), there's no purpose in attempting to
rekey, because the new SA will have the same expiration time. (This
sort of applies also in renewable-TGT or PKINIT or keytab cases when
the KDC isn't available to issue a new TGT, but that could be seen
as starting the rekey process and then failing.) In some
environments, it may make sense to prompt the user to re-enter their
password, but until the new tickets are actually acquired (or the
byte count gets high enough), it makes no sense to continue.
Do you assume that the SA lifetime is truncated to the ticket endtime?
Is the lifetime of application session limited to the service ticket
in usual Kerberized applications?
I.e., if I (kerberized-)telnet to a remote host with a service ticket,
what will happen when the ticket expires? Is the telnet session
# I can't find something on this in RFC 4120 or RFC 2942.
Sidenote: at least when Key Exchange payloads are used,
a ticket and an SA will have independent lifetimes.
I think Mr. Raeburn might point that KINK should obtain new ticket
if the ticket is going to expire.
I accordingly thought we needed to change the 2nd paragraph in the
section 3.6 to
There are no special semantics for rekeying SAs in KINK. That is, in
order to rekey an existing SA, the initiator must CREATE a new SA
followed by either deleting the old SA with the DELETE flow or
letting it timeout (If the initiator needs a new service ticket
it should obtain it in advance). When identical flow selectors are
available on different SAs, KINK implementations SHOULD choose the SA
recently created. It should be noted that KINK avoids most of the
problems of [IKE] rekeying by having a reliable delete mechanism.
But, I found in the section 3
KINK uses Kerberos as the authentication mechanism, therefore a KINK
host needs to get a service ticket for each peer before actual key
negotiations. This is basically a pure Kerberos exchange and the
actual KDC traffic here is for illustrative purposes only. In
practice, when a principal obtains various tickets is a subject of
Kerberos and local policy consideration.
I think when and how getting a servcice ticket is a local matter and
it does not cause interoperability issues so that we don't need the change.