Subject: [AAA-WG]: Recap on remaining issues

From: Pat Calhoun <[email-masked]>
Date: Sun, 11 Nov 2001 15:35:19 -0800

All,

I have proposed a resolution to the remaining issues. This is a recap of
the proposals in an attempt to gain some closure on these, and then issue
the final IDs for last call. 

Issue 94 - This issue needs to be resolved in the transports draft

Issue 199 - This issue needs to be resolved in the transports draft

Issue 211 - I'm really not sure why this issue appears to be bigger than
            it really is. If the HA is known, the Destination-Host must
            exist. Text along these lines has been proposed, and I'd like
            to close this one.

Issue 212 - I believe that a consensus is building that Reverse DNS is 
            the way to solve this issue.

Issue 215 - This issue needs to be fixed in the aaa-keys draft. I've sent
            Charlie a note, since he is the current editor.

Issue 221 - I thought this was solved, but another issue has arisen on
            what to do if a peer only wants encryption and/or authentication.
            Is this a problem?!? Is a boolean AVP required to solve this
            problem?

Issue 222 - Text has been proposed. 

Issue 235 - I propose rejecting this issue (as did Bernard and Jari).

So from the above, I believe that 211 and 221 are the only two that really
still need some work. Any thoughts on these two (or others if you don't think
they are resolved) would be most appreciated.

PatC

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Nov 2001 10:53:00 +0000

Pat,

>             Is this a problem?!? Is a boolean AVP required to solve this

I think this issue was a suggested simplification/efficiency. If it 
turns out that the simpler version doesn't work, isn't the easiest
thing to go back to emitting the expected-* AVPs, since we know that
to work (or at least we think we do:-)?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Nov 2001 06:40:33 -0800

> to work (or at least we think we do:-)?

So I think that we have three options:

1. Leave it as-is (let's determine whether the issue raised is in fact a
   problem).
2. Introduce a new AVP which specifies whether authentication, encryption or
   both is expected.
3. Go back to the expected-* AVPs, which allows a Diameter node to list its
   Diameter/CMS security policy.

Thoughts?

PatC

---

From: Don Zick <[email-masked]>
Date: Mon, 12 Nov 2001 09:20:45 -0500

I like the idea of removing the Expected-Signed-AVP and Expected-Encrypted-AVP and
relying on AVP definitions to know what needs to be signed and/or encrypted.  If
this turns out to be too restrictive, it could be left up to local policies to
deviate from the standard rules.  Might that work?

Don

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Nov 2001 07:36:31 -0800

> deviate from the standard rules.  Might that work?

If allowing implementations to deviate from the rules, and make use of local
policies, chances are we will get into interoperability problems. So some
amount of signalling would be required.

PatC

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2001 10:44:22 +0000

I'd go for 3, on the basis that:

- Its written down & seems to work.
- I believe disallowing all local policy controls (1) is too
  inflexible and we've seen an issue with this posted.
- I haven't seen a detailed proposal for (2), but suspect that
  it would also be effectively inflexible.

Stephen.