RE: Question to Kerberos/Multicast/RSVP

["Hess, Rodney" <rodney.hess@intel.com>]

Hey, Hannes,

I assume you mean Section 7 of RFC 2747 as RFC 2474 is "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Header," which
does not contain the text you are quoting.  FYI, your question would also
apply to <draft-ietf-rap-auth-policy-data-00.txt>.

Yes, all receivers and the KDC must be preconfigured, either dynamically or
statically, with the principal name before the reservation takes place.  I
suspect how this is accomplished is outside the scope of these documents;
hence the short descriptions.  If you feel you have a better approach, you
are welcome to share its merits with the group.

Rodney Hess
rodney.hess@intel.com

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de]
Sent: Friday, June 29, 2001 3:01 AM
To: rap@ops.ietf.org
Subject: Question to Kerberos/Multicast/RSVP


hi!

in section 7 of rfc 2474 the use of multicast with kerberos is described as
follows:

"In the multicast case all receivers of a multicast
   RSVP message MUST share a single key with the KDC (e.g. the receivers
   are in effect the same security principal with respect to Kerberos)."

is this an appropriate assumption since this requires that before starting a
multicast session
a new principal name must be created at the kdc and the information
(principal name and key) must be send to the
participating users (receivers). then the actual reservation can take place
to make use of the above mentioned single key.

the above mentioned procedure is required since it cannot be assumed that
two principals are the same security principal. additionally this creates
problems for accounting.

am i missing something?
how should the exact processing work?

ciao
hannes