Subject: [AAA-WG]: Issue 402 - Closing

From: David Mitton <[email-masked]>
Date: Fri, 11 Jul 2003 14:06:13 -0400

Issues #402:

JARI: Comments marked with "JARI:" DJM: Responses marked with "DJM:" major
snips to document marked with "..."

1.2.  Advertising Application Support  . . . . . . . . . . . . . . .   6

JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc.
DJM: Added.

2.  NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . .   6

JARI: Looking at the contents list, it might make sense to change the
       section titles from "NAS <something>" to simply "<something>"?
       What do you think?

DJM: I like the "NAS".  At least it is a simplification from previously,
everything was NASREQ.
	
...

2.1.  Diameter Session Establishment

    When the authentication or authorization exchange completes
    successfully, the NAS application SHOULD start a session context, and
    MAY send an Accounting START_RECORD message [Base].  The failure to

JARI: The MAY above is a bit weak? Is this a configuration issue
       again, or are NASes generally allowed to skip accounting
       if they feel like it? ;-)
DJM: Yes, I've reworded this per your later comments.
	Accounting should not be skipped if implemented, but the spec
     doesn't require the capability either.

JARI: Is there an AVP which holds the type of failure? Or are all
       EVENT_RECORD messages for this particular error?

DJM:  Yes, typically Termination-Cause, but it depends on the error.

2.2.  Diameter Session Re-Authentication or Re-Authorization

...
JARI: Is this always possible? I think it is possible on PPP, but
       perhaps there are other access types for which it might not
       be possible. Is re-auth possible on all types of WLAN
       links?
DJM: Maybe, maybe not. 	The feature is here, because it is possible on
some services.

JARI: While re-auth is going on, can service still be provided?
DJM: That too would be service specific.

JARI: Shouldn't we somehow take in account also
       Accounting-Realtime-Required AVP from base?

DJM: A Note: is added.

    More information on Diameter Session Termination is in [Base] section
    8.4.

3.1.  AA-Request (AAR) Command

    The AA-Request message (AAR), indicated by the Command-Code field set
    to 265 and the 'R' bit set in the Command Flags field, is used in
    order to request authentication and/or authorization for a given NAS
    user. The type of request is identified through the Auth-Request-Type
    AVP, and the default mode is both authentication and authorization.

JARI: Default... hmm... does this mean Auth-Request-Type AVP
       is optional? Base 8.7 does not talk about this. Please
       clarify. Suggestion: don't talk about defaults.

DJM: On some AAR messages it is.  Because this message is used for
Multi-round exchanges, many	AVPs are not used in all cases.
I believe that the use of a default is obvious.  It also helps with
translation issues.
    ...

8.  NAS Accounting

  JARI: Earlier in the document there was some confusion about when
       accounting messages should be sent.
DJM: This description and the earlier Session description have been
redone.

    Authentication or Authorization transaction and at the end of a
    Session.  The Accounting-Record-Type value indicates the type of
    event.  All other AVPs identify the session and provide additional
    information relevant to the event.

    If Authentication and Authorization are contained in one message
    (typical case), then one START_RECORD should be sent.  If
    Authentication and Authorization occur in seperate transactions, the
    first message should generate a START_RECORD, and the later, an
    INTERIM_RECORD.  For a given session, there should only be one set of
    matching START and STOP records, with any number of INTERIM_RECORDS
    in between, or one EVENT_RECORD.

JARI: Compare to Section 2.1. I'm not sure I understand what "failure
       to start a session" exactly means, but let's assume we do a
       successful authentication, successful authorization, and the
       "fail to start a session". It would be incorrect in this case to
       send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be
       indicated by 2.1. Suggestion: make 2.1 inline with the text
       here.
DJM: Your example is indeed incorrect.  Every START_RECORD MUST be
	paired with a STOP_RECORD.  EVENT_RECORDs are for non-session
     events.
     This text and others related have been rewritten.

  ...
    The corresponding Diameter response is always guaranteed to be
    received by the same Translation Agent that translated the original
    request, due to the contents of the Origin-Host AVP in the Diameter
    request. The following steps are applied to the response message
    during the Diameter to RADIUS translation:

       - If the Diameter Command-Code is set to AA-Answer and the Result-
         Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must
         send a RADIUS Access-Challenge with the Diameter Session-Id and
         the Origin-Host AVPs encapsulated in the RADIUS State attribute,
         with the prefix "Diameter/". This is necessary in order to
         ensure that the Translation Agent that will receive the
         subsequent RADIUS Access-Request will have access to the Session
         Identifier, and be able to set the Destination-Host to the
         correct value. If the Multi-Round-Time-Out AVP is present, the
         value of the AVP MUST be inserted in the RADIUS Session-Timeout
         AVP.
       - If the Command-Code is set to AA-Answer, the Diameter Session-Id
         AVP is saved in a new RADIUS Class attribute, whose format
         consists of the string "Diameter/" followed by the Diameter
         Session Identifier. This will ensure that the subsequent
         Accounting messages, which could be received by any Translation
         Agent, would have access to the original Diameter Session
         Identifier.
       - If a Proxy-State attribute was present in the RADIUS request,
         the same attribute is added in the response. This information
         may be found in the Proxy-Info AVP group, or in a local state
         table.
       - If state information regarding the RADIUS request was saved in a
         Proxy-Info AVP or local state table, the RADIUS Identifier and
         UDP IP Address and port number are extracted and used in issuing
         the RADIUS reply.

JARI: Question: Does the above rules work even in a situation where
       there's been a change to another translation agent due to
       load balancing or a fault?
DJM:  I'm not sure. That would depend on how such a handover was
	implemented, and this spec does not describe or specify such
     behavior even for non-RADIUS cases.

...
10.1.  AA-Request/Answer AVP Table

    The table in this section is limited to the Command Codes defined in
    this specification.

JARI: I don't understand the above comment. Remove?
DJM: This is needed.  I have improved the text.

...
10.2.1.  Accounting Framed Access AVP Table

JARI: I don't fully understand the construction of this table
       vs. the one in the base spec. The above attribute,
       for instance, is included but not discussed in this
       specification. But some other base attributes such
       as Auth-Application-Id are not included. Is this
       an old version of the base table, with the NASREQ
       additions? May I suggest taking a new version from
       base-17...?

DJM: Please name any other AVPs not included?  Are they required for all
	Accounting applications?  Do they have application for NASreq?  I
     will include them.

     The BASE does not, and cannot describe this application, I must.
     This application uses Base AVPs, how it uses them (not what they
     are) must be described here, even if it's just an inclusion that
     says it's allowable.   I have added more verbage to make
     these tables self explanatory.

...
12.  Security Considerations

    The security considerations  of the Diameter protocol itself have
    been discussed in [Base].

    This document does not contain a security protocol, but does discuss
    how PPP authentication protocols can be carried within the Diameter
    protocol. The PPP authentication protocols that are described are PAP
    and CHAP.

    The use of PAP SHOULD be discouraged, since it exposes user's
    passwords to possibly non-trusted entities. However, PAP is also
    frequently used for use with One-Time Passwords (OTP), which do not
    expose a security risk.

    This document also describes how CHAP can be carried within the
    Diameter protocol, which is required for RADIUS backward
    compatibility. The CHAP protocol, as used in a RADIUS environment,
    facilitates authentication replay attacks.

JARI: Any references to the attacks discussed above?

JARI: Maybe there should be some discussion of what it implies
       if authorization-only AAA requests are made, and in which
       cases such usage is safe.
DJM: Submissions are welcome.

JARI: What are the security impacts of RADIUS-DIAMETER translation?
       Are all or only some of the known radius vulnerabilities carried
       onto DIAMETER in such a setup? See reference "Joshua Hill. An
       Analysis of the RADIUS Authentication Protocol.
       http://www.untruth.org/~josh/security/radius/, 2001."

DJM: I have read that document in the past, however, we have tried
to document the Diameter NAS Application protocol in this document, and
avoided including a full treatis on Diameter/RADIUS how-to build a
gateway.  This really requires another document.  If I could make it
relate to my job (what's that?) I'd write it myself.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Jul 2003 22:14:29 +0300

> JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc.

Great!

> DJM: I like the "NAS".  At least it is a simplification from previously,

No problem.

>     doesn't require the capability either.

Is this is in the latest document or on some private version?
I agree with what you say above. But I wonder if there should
be some words about configuration as well. If you implement it,
you may not in all cases need accounting.

> DJM:  Yes, typically Termination-Cause, but it depends on the error.

Ok. Is this described now somewhere?

> DJM: That too would be service specific.

Ok. Are there words warning about the above in the
latest version?

>       Accounting-Realtime-Required AVP from base?

Great!

> I believe that the use of a default is obvious.  It also helps with

Ok.

>    in between, or one EVENT_RECORD.

Ok.

>     This text and others related have been rewritten.

Great, thanks!

>         UDP IP Address and port number are extracted and used in issuing

Ok.

>     behavior even for non-RADIUS cases.

Ok. But maybe the limitation should be documented.

> DJM: This is needed.  I have improved the text.

Ok.

>     these tables self explanatory.

I'll have to take a more detailed look at this later. What
you say makes sense. I'll try to do a check of the tables.

> DJM: Submissions are welcome.

The one below may be sufficient for the second attack.
2869bis talks about some of the PAP attacks, though not
the one discussed above. A ten minute search to the
net on PAP attacks did not reveal anything interesting.
Maybe its too obvious.

> relate to my job (what's that?) I'd write it myself.

Ok.

--Jari

---

From: David Mitton <[email-masked]>
Date: Fri, 11 Jul 2003 15:25:07 -0400

>you may not in all cases need accounting.

Draft 12 is availible from the IETF server.
I don't have a rev ... yet.

Let me try again - Accounting is not a required capability of a NASreq 
application, but if Accounting is implemented, it MUST follow the 
specifications given.  In particular the type and sequence of records must 
be conformant to allow interoperable server implementations.

Dave.