Subject: [Fwd: Re: [AAA-WG]: AAA WG last call on draft-ietf-aaa-isssues-04.txt]

From: "John R. Vollbrecht" <[email-masked]>
Date: Tue, 20 Mar 2001 14:38:17 -0600

Bernard Aboba wrote:

 >  This is the AAA Working Group last call on draft-ietf-aaa-isssues-04.txt
 >  before  sending it on to IETF Last Call. This draft is recommended
 >  for Informational status.  If you have comments on it, please
 >  send them to the authors or to the [email-masked] mailing
 >  list BEFORE February 28, 2001.
http://www.ietf.org/internet-drafts/draft-ietf-aaa-isssues-04.txt

I would like to suggest a couple issues that I do not think have been 
covered. I am unable to access the draft on the ietf repository,
so I am unable to suggest exactly how these would be incorporated in 
the draft.

1. Hop by hop security and audit.

It seems desirable to be able to demonstrate that a valid security 
association existed between servers at the time a transaction occurs. 
This might be accomplished by including a MAC (as proposed for ete 
security) on each message. For those willing to support the
overhead of a MAC this would be sufficient.

Alternatively, the AAA servers might know about hop by hop security 
associations and include an indication of this in useage logs for 
accounting purposes. In RADIUS this indication is in the message 
authenticator. If DIAMETER uses IPSEC or SSL for hop by hop
security a mechanism for providing auditing of the security 
association needs to be described.

2. Managing multiple resources

DIAMETER currently assumes that a Session ID will be created by the 
requestor (NAS) and used by all subsequent proxies. This approach 
seems to mean that adding a resource to a session, for example adding 
an additional ISDN channel to a multilink call, requires a separate
session to be created and then linked somehow to the initial session.

Some method of handling multiple resource sessions associated with a 
single useage session should be described.

Regards

John Vollbrecht

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 26 Mar 2001 14:39:33 -0800 (PST)

> association needs to be described.

As far as TLS is concerned, I think this is a no brainer because there is an
API used to access the protocol. As for IPSec, I am not sure that there is a
standardized way to access the underlying policy database.

Either way, it isn't clear to me how (or why) the protocol specification needs
to expand on this.

> single useage session should be described.

If this is true, then there is something broken in the protocol spec. Could
you tell me what led you to believe that adding resources required a new
session identifier? 

PatC