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

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Mar 2001 07:39:49 -0800 (PST)

Hi,

I have some comments, questions and nits on the above I-D.

1. Some time back on the list, we agreed that Diameter was not all uppercase,
since it wasn't an acronym (although many suggestions were proposed). You will
want to fix your I-D to use "Diameter" instead of "DIAMETER".

2. "The ROAMOPS Working Group has defined a requirement that allows for
the DIAMETER servers..." doesn't quite sound right. A requirement doesn't
"allow" for something, but requires a feature.

3. "This specification introduces the 'P' bit in the AVP Header, which is
defined in [1]." This is a contradictory sentence. First you state it is
introduced here, and defined in the base. You may want to clean up this
sentence. Perhaps "This specification makes use of the 'P' bit in the AVP
Header, which is defined in [1]."

4. Not being a Kerberos expert, I find that the text in section 3.0 is very
confusing. You have the sentence "The KRB-PRIV message carries the Diameter
AVPs encrypted in the Session Key." What does this mean? Why are AVPs encryped
in a session key? (I assume this is a typo).

So if I can assume what you meant here, the AVPs are encrypted inside the
KRB-PRIV, using a session key. 

Further, the KRB-PRIV has a reference to EncryptedData, but the paragraph
following that states that this field really contains the EncKrbPrivPart. So
which one is it? I would think it is EncryptedData, since it is the only one
that has a reference to the CipherText.

The sentence "The enc-part holds an encoding of the EncKrbPrivPart sequence
encrypted under the session key" needs to be clarified. When you state
something is encrypted under a session key, do you really mean it is encrypted
using a session key, or is this some kind of binding that I am unaware of?

5. Section 4.0 is much simpler to understand, but I don't see anywhere where a
reference to a key is made. Is there an assumption that only one key is
pending at any given time, or is one of the those fields a key identifier?

6. I have questions in regards to the following paragraph, which shows up in
section 5.0:

"  The DIAMTER client uses the kerberos service principal for service 
   discovery i.e. to discover the capability of a DIAMETER server to 
   support Kerberos. Since the kerberos service principal is defined 
   per DIAMETER server or proxy only Kerberized DIAMETER servers or 
   proxies would have the service principals registered with the KDC. 
   The KRB_TGS_REQ would fail trying to obtain a ticket for a non 
   Kerberized DIAMETER server or proxy and the NAS would revert back 
   to using the "normal" DIAMETER operation as defined in RFC 2865."

First, it sounds like a NAS would send a Kerberos message to a Diameter
server, which would fail if it didn't support Kerberos. What exactly does this
mean? A Diameter server only handles Diameter messages. Are you instead
stating that a Kerberos message is sent to the Kerberos server on the same
physical entity that is running Diameter? If so, you will want to make that
clearer, as my read of this sounded like Diameter was also handling Kerb
messages.

Second, RFC 2865 is an obvious cut and paste error from another I-D :)

7. The following paragraph disturbs me quite a bit:

"  A valid cross domain Ticket Granting Ticket(TGT) must be cached on 
   the DIAMETER client prior to sending a Kerberized DIAMETER request.  
   Cross domain TGT acquisition is out of the scope of this draft and 
   can happen based on inter domain trust or public key extensions 
   like PKCROSS can be employed to obtain cross realm TGTs. "

When you presented your proposal in AAA, and at the Interim meeting, you also
sort-of hand-waved on this area. Although I understand why you state it is
outside the scope of this specification, the casual Diameter reader could be
fooled by not understanding what this means in terms of signaling through the
Internet. I think that it would be quite useful to show the basic security
relationships that are required between the entities, and how the cross-realm
TGTs are established. This is really crucial in the deployment, and shouldn't
be brushed off as out of scope.

In fact, I would highly recommend that this text even shows up prior to the
BNF definitions, and has its own section. Now that I think of it, I don't see
why section 3 and 4 aren't pushed towards the end of the document. Reading the
BNF structures without understanding what is being done is the wrong approach
IMHO.

8. Please fix up the following text in section 5 "... a KRB_TGS_REQ to the
Ticket Granting Service (TGS) in order to the service principal ticket for the
DIAMETER server."

9. I am quite confused here. Section 5.0 contains:

"The Kerberized
   DIAMETER operation would mostly involve dynamic symmetric key 
   negotiation between DIAMETER peers using the Kerberos Application 
   exchange (KRB_AP_REQ/KRB_AP_REP). The symmetric keys negotiated 
   would then be used to provide integrity protection and privacy 
   protection for the DIAMETER AVPs."

So it sounds like symmetric keys are what's being distributed, right? If so,
then why the following text in section 2.0:

"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."

How can non-repudiation be achieved if both sides have the same key?

10. The following paragraph is plagued with cut and paste error from the
RADIUS draft: "In routing the Access-Request to the home DIAMETER server, the
NAI is typically  used, as described in RFC 2486..."

11. The following text describes how Diameter server discovery can be made. I
can understand why this was done in RADIUS, given that it never bothered to
specify how servers are discovered. However, the base protocol has a section
on server discovery. Could you check whether the text in the base protocol is
not sufficient, and whether section 3.4 is still required?

"The hostname and port of a DIAMETER homeserver can be determined as described
in the section 3.4."

12. Remove "of" in "The NAS will start of by creating a KRB_AP_REQ message..."

13. The text reads "... Kerberos-Endtoend-Auth AVP ..." However, I thought at
the meeting you claimed that your proposal make use of the ICV and
Encrypted-Payload AVPs. is this the case? If not, I can remove these AVPs from
the base protocol. I had left them in the -01 in case your proposal was
chosen, and I didn't want to have to rip out text, and put it back in -02.
Some guidance would be appreciated.

Wait! I read further and now I am confused. Is the following correct?

Kerberos-Endtoend-Auth AVP is used to carry Kerberos payload used to establish
the session key? If so, is this sent in parallel with any request? This isn't
clear to me. If it is not sent in parallel, when is it sent? In which Diameter
message?

The "if end-to-end security is used, then an..." talks about an Integrity
Checksum. Is this something present in the ICV or something else?

14. s/SHOULD not/SHOULD NOT/

15. The following "DIAMETER proxies SHOULD not modify the Kerberos-Data AVP
and the Kerberos-Endtoend-Auth AVP since this AVP is meant for DIAMETER end
servers." How does a server know it is an end server, and specifically *the*
intended end server? Is there some identity hidden somewhere in an AVP that
states that the end destination of the message is in order to proxies to know
where to send the message?

16. It is now clear to me that a terminology section would be really useful.
Perhaps the most commonly used term in this I-D could be defined at the
beginning. You claim that a kerberos session key is the same as the client
session key, but I know that some RADIUS and Diameter people will get confused
if they've ever used the common RADIUS source base, which includes the clients
file, which also contains the secret. I am proposing this to reduce any
possible confusion on the part of the reader.

17. "In case of an error in Kerberos authentication, an Access-Reject is sent
with a Kerberos-Endtoend-Auth AVP containing the KRB_ERROR message in the
Kerberos authentication TLV." Cut and paste error. Again, is this done in
parallel with a valid request, or prior to? If prior to, then a new message
set should be created.

18. The AVP codes assigned conflict with the Mobile IP extension, and with
each other :)

19. Copyright year should be 2001.

PatC

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 12 Mar 2001 21:51:50 +0530 (IST)

pat,

   hi! Thanks a lot for your comments. I will clean up the draft
   and respond to your questions. I have been working on 
   changing this draft to use GSSAPI for Diameter security 
   instead of raw kerberos which would be the proposed 
   solution. That's the reason I didnot originally send this 
   draft on the list. 

  kaushik!

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Mar 2001 18:21:07 +0000

Hi Kaushik,

Now I'm confused. At the Interim meeting I thought there was 
more-or-less concensus that GSS-API only makes things worse
here, and that you'd then decided not to include GSS-API in
your proposal. Your answer below makes it look like you're
putting GSS-API back(?) in, even though your -01 draft was 
posted a couple of weeks after the interim meeting.

So, (if only to take me out of my confused state:-), which 
are we discussing - kerberos with or without GSS-API wrappers? 
And which version do you plan to describe at the meeting next 
week, this one or the one with GSS-API and responses to Pat's 
other comments? (BTW: Its getting *very* close to the meeting
to expect most folks to have read another version, even if sent
directly to the list.)

I also strongly agree with Pat's comment that omitting the 
description of how the tickets get to the originating node 
(inter-realm TGTs and all that) means that a very large chunk of 
the implementation and deployment/configuration work required 
to support your proposal is not described.

Regards,
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: Kaushik Narayan <[email-masked]>
Date: Tue, 13 Mar 2001 12:45:15 +0530 (IST)

stephen,

   hi! The use of GSSAPI makes sense and apart from
   the forward extensibility it also provides a framework 
   for management of Security Associations (SA).

   I will send the draft out on the list in next couple of
   days, I am exploring different alternatives to align the draft 
   with requirements for e2e security from the interim meeting

   * NAS need not authenticate to the homeserver, only 
     homeserver needs to authenticate to NAS.
   * Lightweight NAS.
   * Minimal administrative overhead on the NAS.

   I planning address deployement issues as a seperate section
   in the draft.

   kaushik!

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 13 Mar 2001 17:39:49 +0530 (IST)

pat,

   hi! Thanks for the comments. Some of sections in the current
   draft (raw Kerberos) would be removed in the new draft (GSSAPI). 
   Anyways I have tried to address all your queries. 
   
   Find my reply inline. 

> want to fix your I-D to use "Diameter" instead of "DIAMETER".

   I will fix this.

> "allow" for something, but requires a feature.

   I will fix this. This line is present in the CMS strong security
   draft as well.

> Header, which is defined in [1]."

    will do that.

> using a session key, or is this some kind of binding that I am unaware of?

  All of this should read as "encrypted using the session key".

  The KRB-PRIV contains EncKrbPrivPart in the enc-part field.

  The EncryptedData is the ASN.1 definition of all messages encrypted using 
  the Kerberos session key. 

> pending at any given time, or is one of the those fields a key identifier?

   The Kerberos session key is used to generate the checksum.

> Second, RFC 2865 is an obvious cut and paste error from another I-D :)

   Well the KRB_TGS_REQ is the request for the service principal ticket
   which is sent by the DIAMETER client to the KDC. If a DIAMETER server 
   doesnot support Kerberos it won't have a service principal registered
   with the KDC. The KRB_TGS_REQ would fail sent by the DIAMETER client
   to the KDC would fail.

   This section is a cut and paste from my Kerberized Radius draft.

> BNF structures without understanding what is being done is the wrong approach

   The new draft would contain a section on deployment of Kerberos and address
   cross realm issues as well. 

> Ticket Granting Service (TGS) in order to the service principal ticket for the

   I will fix this.

> How can non-repudiation be achieved if both sides have the same key?

   This line should be deleted, non-repudiation cannot be achieved with
   symmetric keys. 

> NAI is typically  used, as described in RFC 2486..."

   This will be fixed.

> "The hostname and port of a DIAMETER homeserver can be determined as described

   Will do.

> Checksum. Is this something present in the ICV or something else?

   The model of key exchange was that every Diameter session would
   perform a key exchange and the first set of Diameter message of the 
   session (authentication/authorization) would carry the Kerberos
   key exchange messages in AVPs. The key exchange is done in parallel
   with the Diameter exchange.

   The new draft uses the Security Association (SA) model and the
   E2E-SA-Setup-Request and E2E-SA-Setup-Answer commands would be
   used for key exchange.

   I was planning to use Kerberos for both e2e and hop-by-hop as well.
   I sent out an email asking for feedback on the proposal to use 
   object level security for hop-by-hop but recieved no response. 
   This draft has a mention of Kerberos for hop-by-hop but if there is 
   consensus in the group for use of IPSEC/SSL for hop-by-hop then 
   I will drop the use of Kerberos for hop-by-hop in the latest
   draft. In case use of Kerberos for hop-by-hop is dropped then you
   can remove the ICV and Encrypted-Payload AVPs from the base 
   document.

> where to send the message?

   Kerberos service authentication is done per Diameter server. In case the 
   Diameter homeserver which recieves the request is different from
   the one in the service principal then the kerberos authentication
   would fail. This model is based on the assumption that the Diameter
   homeserver discovered using DNS is the same as the homeserver which
   recieves the request. There is nothing in the packet to tell a proxy
   to forward the request to that particular homeserver. Since this 
   might not work out an alternative was to use a service principal
   per domain like [email-masked] instead of diameter/[email-masked]
   in which case the request could be sent to any diameter server in that
   domain. In this case all Diameter servers in domain FOO.ORG would be
   valid Diameter servers.

   Anyways I am planning to change the model of authentication in the 
   latest draft.

> possible confusion on the part of the reader.

   I will do that.

> 18. The AVP codes assigned conflict with the Mobile IP extension, and with

  Will change the AVP codes.

> 19. Copyright year should be 2001.

  I will fix this.

 thanks,
  kaushik!

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Mar 2001 12:42:24 +0000

Kaushik,

I've another question. Might be that I'm not upto date on Kerberos
implementations, but rfc150 says (section 1.2):

"  +    Each host on the network must have a clock which is "loosely
        synchronized" to the time of the other hosts; this
        synchronization is used to reduce the bookkeeping needs of
        application servers when they do replay detection.  The degree
        of "looseness" can be configured on a per-server basis.  If the
        clocks are synchronized over the network, the clock
        synchronization protocol must itself be secured from network
        attackers."

Now, I remember this being a PITA when we were trying to deploy SESAME
(which had Kerberos as an authentication option, if you don't know what 
SESAME was...it doesn't matter anymore;-).

So, my question is: does you proposal require loosely synchronized 
clocks across all Diameter nodes that want e2e? If so, is time synch
already supplied by other parts of Diameter or is it a new requirement
for Diameter nodes?

Regards,
Stephen.

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 13 Mar 2001 19:37:45 +0530 (IST)

stephen,

    hi! Kerberos would require loose clock synchronization across 
    Diameter nodes that want e2e. Administratively Diameter nodes 
    can configure the maximum allowed clock skew, the default is 
    five minutes. 

  kaushik!

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 13 Mar 2001 14:02:40 -0800

Existing implementations don't require the application client and
application server to have synchronized clocks. If the clocks are not
synchronized, then an error message is returned to the client which allows
the client to make a subsequent AP request with a timestamp that will be
acceptable to the server.
(But the extra round trip is not necessary when the client and server's
clock are within some fixed skew period - typically 5 minutes but the skew
period can be longer).

Jonathan