[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Theodore Y. Ts'o: Re: Daemon Recovery]
--- On Fri, 19 Sep 1997 17:42:59 -0400 "Theodore Y. Ts'o" <tytso@MIT.EDU> wrote:
> It seems pretty obvious, but given that our previous conversation had
> talked about "host", and we hadn't really thought about the
> user-oriented keying, it seems appropriate to remind ourselves that
> host-based keying might not be all there is.
Yes. And thank you very much for remembering and reminding us
all of that.
> You bring up a good point; in the case of user-based keying, life
> becomes much more difficult. I think most folks were assuming that the
> keys in use were host (TCB) based, not user-based --- or at the very
> least, unprivileged users would not have access to the keying material.
Unprivileged users ought not have access to keying material. This ought
to be noted very specifically somewhere in {ARCH, ESP/AH}. Vaguely I
think that this once lived in the Security Considerations text of the
current RFCs, but I haven't verified that just now. Unfortunately,
Windows/DOS/MacOS do not have the concept of an unprivileged user [Sommerfeld].
> I'd think the right thing to do is to specify that when you finish
> negotiating an SPI, you can invalidate all previous SPI's corresponding
> to the same public key which was used to establish the new SPI. This
> would work for either host or user based keying.
If you'd change "to the same public key which was" into text more like
"to the same identity which was", then I think I'd be a little happier.
I don't think an implementation is required to retain the "public key"
in the SA state, whereas implementations are supposed to retain the
"identity" information in the SA state.
While I think that "identity" will frequently be identical to "IP address"
in many operational situations, its important to design/implement for the
general case where "identity" might be something else, such as"
FQDN
USER_FQDN
SUBNET
...
Ran
rja@inet.org
References: