Subject: [AAA-WG]: Comments on draft-kaushik-diameter-strong-sec-02.txt

From: Pat Calhoun <[email-masked]>
Date: Wed, 14 Mar 2001 14:15:29 -0800 (PST)

ok, here are my comments on the new version:

1. "The Diameter base protocol [1] defines message integrity and AVP
   encryption using symmetric transforms to secure the communication
   between two Diameter nodes."

   Since you no longer use these, I will remove them from the base protocol,
   so this sentence was be removed in your next version. Please go through the
   I-D as there are many other places where you refer to the ICV, and how it
   works. replace that with your favorite hop-by-hop protocol (e.g. TLS or
   IPSec).

   (FWIW, the CMS I-D will also include such changes in its next revision)

2. "The Mobile-IP and NASREQ Working Groups have stated in [6, 7, 8] that 
   non-repudiation is a requirement for AAA data, such as accounting records."

   I *thought* you agreed that Kerberos cannot provide non-repudiation in your
   last response to me. Therefore, I am curious as to why you insist on keeping
   this sentence in the I-D, unless it is to make it clear that your proposal
   doesn't meet the requirements ?!?!

3. It is my understanding that only the CMS or the Kerberos approach will be 
   selected, so refering to messages created in the CMS I-D is probably not a 
   good long term approach.

4. Section 3.0. Thank you very much for this explanation. I think it really
adds 
   alot to the proposal. I believe that this type of language will ease 
   interoperability.

5. Section 3.0, at the end of step 2, you state " This ESSA message WOULD
contain 
   ... - List of AVPs to be protected." This one really confuses me. An SA
should
   be created for a long time (tm). So given that one has no idea what AVPs
will 
   be provided in the future, should all possibly encrypted AVPs be listed, or 
   rather just subset of those? Which ones? I am confused with this sentence.

6. Section 3.0, step 3. I believe this proposal is "abusing" the ESS command 
   codes. It appears as if this step causes an Answer to be sent in response
to 
   an Answer. Is this correct?? Diameter doesn't work this way, so either a new
   ESSR is to be sent, or another set of messages should be created.

7. The figure in section 4.0 does not seem to match section 3.0. Doesn't step
   3 require that another ESSA be sent back in response to an ESSA?

8. "The key exchange of the Kerberos GSS mechanism WOULD take only
   half a round trip and the SA creation WOULD take one round trip. "

   Now I am confused because the diagram only shows a single round trip, not
   1.5 round trips.

9. Sorry for the perhaps dumb question, but what the #ell is 
      "123 456, 768" ",768 910" "123 456"

   I don't understand the random placement of commas and quotes.

10. If you don't need new Result-Codes, you can get rid of section 7.0

11. Oh, and an acknowledgement to the authors from whom you "borrowed" text
would 
    be nice too :)

See y'all next week,

PatC

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 15 Mar 2001 12:53:20 +0530 (IST)

pat,

   hi! Thanks for your comments. Find my reply inline.

>    (FWIW, the CMS I-D will also include such changes in its next revision)

   I will change this.

>    doesn't meet the requirements ?!?!

   I will remove this line.

>    selected, so refering to messages created in the CMS I-D is probably not a 

  I will add new messages to my draft. 

>    rather just subset of those? Which ones? I am confused with this sentence.

   The list should contains all AVPs that need e2e protection (both encryption
   and origin authentication). 

>    ESSR is to be sent, or another set of messages should be created.

   I will use new messages for this.

>    3 require that another ESSA be sent back in response to an ESSA?

    Section 3.0 describes the process of context establishment for any
    GSS mechanism which may take n round trips. 

    Section 4.0 illustrates the actual usage wherein GSSAPI would use
    the Kerberos v5 mechanism. In this case the Kerberos GSS mechanism 
    is used in single-TGT mode (this is without the mutual authentication).
    This mechanism completes key exchange with a single message sent from 
    the client to the server to authenticate the client to the server 
    and exchange keys.  The server doesnot reply to client's request. 

    The client here is the Diameter homeserver which wants to authenticate
    itself to the server(NAS) and GSS token would be sent from the 
    homeserver to the NAS in the ESSA. The NAS doesnot reply back. 

    So the SA setup involves one ESSR and ESSA.

    This is the singficant changes made in this proposal are.

    * The security context (SA) is initiated by the Diameter homeserver
      since the parameters of the SA (like TTL) are defined by the 
      based on the policy.

    * The process of setting up the security context  using the Kerberos v5
      mechanism takes one single message from the homeserver to the NAS.

    * Since the NAS is the GSS (Kerberos) server (as opposed to the client
      in previous proposals), the NAS neednot have security tokens from
      third party servers and the NAS neednot communicate with the KDC.

    * GSS takes care of the context management (SA management).

>    Now I am confused because the diagram only shows a single round trip, not

    Well the sentence is not very clear. It should read

    The key exchange of the Kerberos GSS mechanism WOULD involve a
    single message from the homeserver to the NAS.

> 9. Sorry for the perhaps dumb question, but what the #ell is 

   Well the quotes represent different examples of what the E2ESecureList
   can contain. There are three illustrations given.

   1>  "123 456, 768"

     AVPs with codes 123 and 456 needs confidentiality and 768 needs
     origin authentication.

   2>  ",768 910" 

     AVPs with codes 768 and 910 need origin authentication.

   3> "123 456"

     AVPs with codes 123 and 456 need confidentiality protection.

> 10. If you don't need new Result-Codes, you can get rid of section 7.0

   I will look at that.

> 11. Oh, and an acknowledgement to the authors from whom you "borrowed" text

   sure.

  kaushik!