Subject: RE: Question to Kerberos/Multicast/RSVP

From: "Hess, Rodney" <[email-masked]>
Date: Wed, 18 Jul 2001 18:19:56 -0700

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
[email-masked]

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Friday, June 29, 2001 3:01 AM
To: [email-masked]
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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 20 Jul 2001 10:05:00 +0200

# hi rodney!

Hey, Hannes,

# yes - a typo.

# maybe your are right with the statement that this should be outside the
scope
# of the document. but in the case of roaming users a kerberos based
authentication is
# more difficult to accomplish if the principal name and the realm name of
the
# first hop router (or pdp) are unknown
# and no specific procedure is specified to obtain this information.
# there may be some mechanisms to learn the identity of the first hop router
# (or pdp) to which the user
# should authenticate but it seems to be difficult for a mobile node to
quickly
# figure this out. hence it seems that the approach of using kerberos is
well suited
# for stationary environments where everything is pre-defined (see windows
2000) but
# in the mobile case some issues are still open.

# ciao
# hannes

Rodney Hess
[email-masked]