RE: Questions regarding Session & Media Authorization

Hi,

Thanks for your comments. In fact, the draft just went under an IESG review.
They
expressed similar comments. We are now in the process of clarifying a few
points
in the draft and should publish a revision shortly.

We hope that the clarifications will answer your comments.

L-N



> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email protected]]
> Sent: Monday, June 10, 2002 7:14 AM
> To: [email protected]
> Subject: Questions regarding Session & Media Authorization
> 
> 
> hi
> 
> it was interesting to read your document about session and media
> authorization drafts. the idea of linking different protocols 
> that somehow
> depend on each other (sip & rsvp) with regard to the 
> authorization phase
> seems to be very useful. however by reading your documents some
> comments/questions came into my mind:
> 
> in [framework] you describe three models: Coupled Model, 
> Associated Model
> and the Non-Associated Model
> from your description it was not clear to me whether in one 
> of the models
> crypgraphic processing (related to the token) needs to be done by the
> first-hop router (Edge Router). i assume that no 
> cryptographic verification
> takes place at the edge router.
> 
> in [auth] you describe different means to protect the 
> information inside the
> token. the means for protection seem to be strongly related 
> to rsvp which is
> not obvious to me. the choice for including non-cryptographic 
> protection
> (ascii and unicode credentials) are difficult to understand 
> since you pass
> the token to the end-host and mention in [framework] that the 
> end-host is
> not trustworthy. hence i would suggest to remove these 
> credentials since
> they provide no use. the use of kerberos might be difficult 
> in practice
> since the entity issuing the token needs to know the who is 
> going to verify
> it (appart from the message size ~ 500bytes for the kerberos 
> token). the
> verification steps of the kerberos ticket as explained in 5.3 
> of [auth] seem
> to be wrong: the verifying entity receives the session ticket 
> and decrypts
> it to retrieve the session key. this key is then used to 
> verify the keyed
> message digest with either HMAC-SHA1 or HMAC-MD5 (or digital 
> signature as
> you call it).
> 
> the usage of pk-based credentials also seems to be adopted 
> from rsvp. the
> fact that pk-based credentials are not really used is not 
> really promising.
> additionally there are concerns related to the size of the 
> token in case of
> pk-based credentials and the digital signature. in section 8 
> of [auth] you
> state that pk-based credentials have an advantage of good 
> scalability but it
> infrastructure support. since there are only a few entities 
> creating the
> token and only a few entities verifying the token scalability 
> does is no
> scalablity problem.
> 
> in [framework] you describe the Non-Associated Model whereby no
> trust-relationship exists between the policy servers (RCD and 
> SCD policy
> servers). why should someone rely on the policy decision of a 
> policy server
> which is not trusted. if there is a trust relationship 
> between them why not
> to establish a session key to verify the token or to exchange 
> the required
> information?
> 
> my main question is: why is it necessary to include so much 
> information into
> the token (qos parameters, credentials etc. - e.g. section 
> 3.3.8 of [auth])
> although this information could easily be exchanged between the policy
> servers. all they need is only a "pointer"/identifier to the stored
> information. section 6. "The Associated Model <<using Two 
> Policy Servers>>"
> in [framework] shows such an interaction between the two 
> types of policy
> servers. hence in such a case the token is much smaller since 
> it only has to
> contain the necessary information, the protection of the 
> token is simplified
> by only using a keyed message digest. finally bandwidth is preserved
> (consider that each session creates a token which has to be 
> sent to the
> end-host and back).
> 
> additionally you should include a short statement about what 
> prevents a user
> from reusing an old token.
> 
> what do you think?
> 
> ciao
> hannes
> 
> [auth]	"Session Authorization for RSVP",
> <draft-ietf-rap-rsvp-authsession-02.txt>
> [framework] "Framework for session set-up with media authorization",
> <draft-ietf-rap-session-auth-03.txt>
> 
> 
> 
>