RE: PLEASE HOLD on: Protocol Action: Session Authorization for RS VP to Proposed

Scott asks:
> Can you forward me what the issue was?
> Thanks.
> 	-Scott

Appologies, I should actually have copied this to the list
right away last Week..  Anyway, here it is attached below

I first thought that maybe it was a matter of answering the 
comments by Louis... turns out that a few changes had to be
made to the doc (that Louis will post as I expect).

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: donderdag 31 oktober 2002 22:11
To: Louis-Nicolas Hamer (E-mail)
Cc: Eric Rescorla (E-mail); Steve Bellovin (E-mail); Randy Bush (E-mail)
Subject: FW: draft-ietf-rap-session-auth-04.txt


Louis, sorry, but it seems we did miss to re-evaluate
some comments/questions from Eric.

Can you quickly try to address his comments/questions.
Specially important are:

   The items that are potentially serious are 4.1.1 
   and 4.2. In those cases I'm not at all clear on what 
   the authors intend. 4.1.1 may have a simple answer 
   (we should ask the authors). We should ask about 4.2
   as well.

Sorry that I overlooked these when re-evaluating the latest 
revision. First let us (quickly) have answers and/or your
views, then let us see what we can still do about it at this 
point in the process. I am not even sure you ever saw these
before (I was under the impression that you did have them,
but I now see no proof of that in my email archive.

Thanks,
Bert 
------------------
To: [email protected], [email protected]
Subject: More on RSVP Auth
Mime-Version: 1.0 (generated by tm-edit 1.8)
Date: Fri, 20 Sep 2002 10:14:08 -0700
From: Eric Rescorla <[email protected]>

Ok, I've reread the document. It's much improved but I've
still got some issues.


S 3.3.1
Realistically, when would you use DNs? It looks like they're
only used to specify shared keys. The same question applies
to URIs. What's the target of the URI supposed to be?

What are the contents of the X509_V3_CERT id type supposed
to be? No ASN.1 type is specified here.

S 3.3.3
I'm trying to figure out how to interpret the source address.
In particular, is the FQDN ever mapped to an IP address here?
If so, that seems problematic.

S 4.1.1
I don't understand how key rollover works for shared symmetric
keys. Is there some key ID value that indicates whether the 
old or new key is being used?

S 4.2
This still seems under-specified to me. What's the protocol
that the router/PDP uses to contact the authorizing entity?

S 4.3.1.1 
It's still pretty unclear which certificates go where. S/MIME
has it's own certificate carrying mechanism and then there's
also the X509_CERT identity payload.

S 4.3.1.2
A lot of the terminology in the PGP section appears to be
PKIX terminology... AFAIK, PGP doesn't have CRLs or distinguished
names....

S 5
I'd put this before the detailed message descriptions. I think
it would make it easier to understand. 


General questions/comments
(1) It appears from rereading that the auth token duplicates
a lot of data in the RSVP request. Is that so? Is it considered
a problem?

(2) It appears from the text that the idea here is that 
Policy Servers keep a cache of authorized sessions (using
SESSION_IDs as lookup keys). Is there some provision
for self-authenticating tokens instead? Or is that just
a local matter?

(3) I'd like it made more clear that proper clock synch is
really important for the anti-replay stuff to
work properly.

Nits:
There are a lot of special characters (\226) here.