Diameter Mobile IPv4 Application
draft-ietf-aaa-diameter-mobileip-20

[Note]: 'Waiting for IANA to give OK on IANA considerations section;
Once we receive that, then Thomas can clear his DISCUSS.
So back on 19 aug telechat to force that decision.' added by Bert Wijnen

On hold to fix this issue:
-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: woensdag 16 juni 2004 02:55
To: iesg@ietf.org
Subject: Comment on Diameter NASREQ, EAP, MIPv4 (fwd)


Yoshi Ohba has found an error that exists within all several Diameter
Application drafts -- Diameter NASREQ, EAP and MIPv4.  This concerns the
use of Application-IDs in those documents.

Based on the Application-ID guidelines of RFC 3588, the Diameter NASREQ,
EAP and MIPv4 documents are not permitted to allocate new Application-IDs
because no new mandatory AVPs are defined in those documents.  Re-using
Diameter Base commands will enable Diameter agents (such as
Diameter/RADIUS gateways) to operate across a range of applications with
no code changes.

Diameter EAP & NASREQ use ACR/ACA, RAR/RAA, STR/STA and ASR/ASA commands.
Diameter MIPv4 uses ACR/ACA, STR/STA and ASR/ASA commands.

WG and editor still strugling.
But the aaa-keys doc is now in IETF Last Call, so no holdup on that any more (or so I think).
So I expect a revision REAL SOON now.

[Note]: 'This doc is back. It has been on IESG agenda in Nov 2002 and again mid 2003. Since has been so long,
I prefer to have IESG review it again instead of just trying to figure out if DISCUSSes have been addressed.' has been cleared by Bert Wijnen

[Ballot discuss]
Nit: it speaks of xyz.com instead of example.com

2.2 says

      Security considerations may require that the HAR be sent directly
      from the AAAH to the HA without the use of intermediary Diameter
      agents. This requires that a security association between the AAAH
      and HA be established, as in Figure 4.

If the HA is in the foreign network, how does AAAH get suitable
information to set up a secure session?

7: "the keys in this regime are symmetric in the sense they are
      used in both directions" is a very bad idea. 

------
1.6: What is a "preconfigured shared security association"? Do you
mean a preshared secret? A security association comprises far more
than just a key.

I have not evaluated the security of the scheme in this section, since
it depends on another draft, and possibly on the security of MobileIP
itself. Can we really even consider this draft until those are done?

1.10: What firewall rules? Are the agents supposed to tell their local
firewalls to open up some holes?

5.2: 64 bits is not sufficient for a key. Why not just mandate 128,
instead of strongly recommending it?

5: I confess that it still isn't clear to me how the home and foreign
agents know authoritatively who each other are. Then again, that's
always been my main complaint about AAA. But here they're handing out
keys.

[Ballot discuss]
I am uncomfortable proceeding with this document without seeing [MIPKEYS]
too. The reference was difficult to track down. Once I finally found it,
it is in 'Publication Requested' state.

[Note]: 'This doc is back. It has been on IESG agenda in Nov 2002 and again mid 2003. Since has been so long,
I prefer to have IESG review it again instead of just trying to figure out if DISCUSSes have been addressed.' added by Amy Vezza

[Note]: 'This doc is back. It has been on IESG agenda in Nov
2002 and again mid 2003. Since has been so long,
I prefer to have IESG review it again instead of just
trying to figure out if DISCUSSes have been addressed.' added by Bert Wijnen

[Ballot discuss]
> sufficient for protecting session keys. (It should be noted that the
> CMS security application is referenced as informative in this
> application and the usage is only a recommendation.) However, if a

recommendation != normative? A recommendation to do something is
normative, IMO.

> without Diameter agents. When deployed in an environment with
> Diameter agents, the keys must be encrypted by means described in
> [CMS].

Seems normative to me...


> 1.9 Fast Handoff support
>
> This application requires that foreign agents issue an AMR upon
> receipt of the first registration message from a mobile node,
> regardless of the fact that the mobile node MAY have been previously
> authorized to another foreign agent.
>
> The Mobile IP Working Group is currently investigating fast handoff
> proposals, and the Seamoby WG is looking at creating a protocol that
> would allow AAA state information to be exchange between foreign
> agents during a handoff. These proposals MAY allow future
> enhancements to the Diameter protocol, in order to reduce the amount
> of Diameter exchanges required during a handoff.

A bit of a nit, but the MAY above doesn't seem right. It sounds like
you are just trying to say "future work may relate". But MAY is a
statement about choices to implement, and its premature to use that
terminoligy here.

Also, IANA had the following question. Did these get responded to (I
don't see the email trail, but I might have deleted it...)

[Ballot discuss]
1.6: What is a "preconfigured shared security association"? Do you
mean a preshared secret? A security association comprises far more
than just a key.

I have not evaluated the security of the scheme in this section, since
it depends on another draft, and possibly on the security of MobileIP
itself. Can we really even consider this draft until those are done?

1.10: What firewall rules? Are the agents supposed to tell their local
firewalls to open up some holes?

5.2: 64 bits is not sufficient for a key. Why not just mandate 128,
instead of strongly recommending it?

5: I confess that it still isn't clear to me how the home and foreign
agents know authoritatively who each other are. Then again, that's
always been my main complaint about AAA. But here they're handing out
keys.

Date: Sun, 1 Jun 2003 08:05:50 -0700 (PDT)
From: Bernard Aboba
To: Randy Bush
cc: David Mitton , Bert Wijnen ,
  housley@vigilsec.com
Subject: Re: draft-ietf-aaa-diameter-mobileip-14.txt

...

Next Steps:
===========

1. Comments from Thomas Narten and Russ Housley to go into draft tracker.
2. Tony to add the text based on RFC2869bis and Diameter Nasreq
  app. into the Diameter-MIPv4 app to deal with impersonation, and
  authorization.
3. If there are any true keys being sent (not Nonces) via proxies, we need
  to make those AVPs go end-to-end via redirects. No need to reference
  CMS, since AAA WG will not be going ahead with CMS.
4. Tony to add clear diagrams showing what messages are passing between
  what entities and where keys and nonces go.  This is essential if the
  IESG is to understand the relationship between the entities and what
  quantities are possessed by each party and passed back and forth
  between them.
5. Try to get this all wrapped up in a months time.
6. Tony to discuss with Tom to get the AAA Keys draft completed.
7. Bernard to setup a teleconf next month (June) to ensure all AD
  comments have been addressed in revised documents. By then we are
  expecting a -15 draft addressing IESG comments.

From: Thomas Narten
To: iesg-secretary@ietf.org
Date: Wed, 21 May 2003 08:57:13 -0400
Subject: discuss comments on draft-ietf-aaa-diameter-mobileip-14.txt

My discuss comments need to go into tracker. Thanks.

Thomas

>    sufficient for protecting session keys. (It should be noted that the
>    CMS security application is referenced as informative in this
>    application and the usage is only a recommendation.) However, if a

recommendation != normative? A recommendation to do something is
normative, IMO.

>    without Diameter agents.  When deployed in an environment with
>    Diameter agents, the keys must be encrypted by means described in
>    [CMS].

Seems normative to me...


> 1.9  Fast Handoff support
>
>    This application requires that foreign agents issue an AMR upon
>    receipt of the first registration message from a mobile node,
>    regardless of the fact that the mobile node MAY have been previously
>    authorized to another foreign agent.
>
>    The Mobile IP Working Group is currently investigating fast handoff
>    proposals, and the Seamoby WG is looking at creating a protocol that
>    would allow AAA state information to be exchange between foreign
>    agents during a handoff. These proposals MAY allow future
>    enhancements to the Diameter protocol, in order to reduce the amount
>    of Diameter exchanges required during a handoff.

A bit of a nit, but the MAY above doesn't seem right. It sounds like
you are just trying to say "future work may relate". But MAY is a
statement about choices to implement, and its premature to use that
terminoligy here.

Also, IANA had the following question. Did these get responded to (I
don't see the email trail, but I might have deleted it...)

From: "IANA"
To:
Cc: , ,
  , ,
Date: Thu, 17 Oct 2002 13:27:33 -0700
Subject: RE: Last Call: Diameter Mobile IPv4 Application to Proposed Standard
Importance: Normal

IESG:

The IANA has reviewed the following Internet-Draft which is in Last
Call: , and has the
following comments with regards to the publication of this document:

9.0  IANA Considerations
            9.1  Command Codes
            9.2  AVP Codes
            9.3  Result-Code AVP Values
            9.4  MIP-Feature-Vector AVP Values
            9.5  MIP-Algorithm-Type AVP Values
            9.6  MIP-Replay-Mode AVP Values
            9.7  Application Identifier

Do these registrations go in an existing registry?  If so which
one?  Also, in the IANA Considerations section it mentions the
following:

This specification assigns the values 260 and 262 from the Command
  Code namespace defined in [DIAMBASE].

[DIAMBASE]    P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens,
              "Diameter Base Protocol", draft-ietf-aaa-diameter-12.txt,
              IETF work in progress, July 2002.

The above document, also in last call, has an IANA Considerations section
that indicates there are no IANA Actions.  This seems contradictory.
There are multiple references to defined parameters in [DIAMBASE].

This is a bit confusing.  If we have misunderstood the IANA Considerations
for this document, please let us know.

Please respond to the IANA about our concerns with regards to this
document.  Failing to do so may cause delay of the approval and
publication of your document.

Thank you.

Michelle S. Cotton
(on behalf of the IANA)

From: "Wijnen, Bert (Bert)"

If you look at draft-ietf-aaa-diameter-15.txt, page 40, sect 4.4,
then you will see that they use IPAddress to represent IPv4 and
IPv6 addresses.

I wondered what your comments would be, given the fact that you
guys took a real good look at IP (or INET) addresses when you
worked on the INET-ADDRESS-MIB.

For me, this use of IPAddress seems at least confusing, and it
also does not seem future-proof.

From: "Steven M. Bellovin"

In a number of places below, I'm not necessarily asking for changes to
the text.  But there are some things that need justification, either
within the document or just in email to me and the IESG. 

1.4 It would be good to define "user".  I *think* that "user" means
"the entity requesting or using some resource, in support of which
a Diameter client has generated a request" or some such.  I'm
trying to avoid confusion in discussions of authentication -- is
it the Diameter node or the resource-requesting entity that is
being authenticated?

The definition of "end-to-end security" needs to be improved.

2.1 ECONNREFUSED is a Unix errno value.  Probably, OS-independent
terminology should be used.

Does "RESET call" mean "send a TCP RST bit" (or the SCTP
equivalent?  Or does it mean that a connection should be
terminated without benefit of the DPR exchange?

2.1.1 How many SCTP streams should be created?  May be created?

2.8.1 Use example.net and example.com?  (Same in 4.5.1)

2.8.3 It is very far from clear to me that redirect agents are or should
be application-agnostic.  Is routing on the contents of
application-specific fields to be disallowed?  I note that
6.13 permits per-user redirection, and user names are not
in the routing table defined earlier.  (I'm perfectly
happy with the answer "the WG has considered and rejected this
point".) 

2.8.4 The description here makes it clear that the phrase "end-to-end
security" is not, in fact, accurate.  If that transform can (or
should) be applied by an intermediate node, which is strongly
suggested by this section, it is not "end-to-end".  I suspect
that something like "object security" is closer, though still
not quite right.

3 What purpose is served by the T bit?  Given that the underlying
network may be duplicating packets -- a few months ago, I was
seeing up to 90% duplicates on my local loop, with no apparent
ill effects on the stack -- why is there some advantage to
trying to convey that information in Diameter?  It almost makes
sense if set only when the application has switched peers before
the retranmission, though it's still not clear to me what
the receiver of such a message would do with the information.

Should the spec indicate that the reserved bits MUST be ignored
by receivers, rather than sending an error?  It makes it hard to
start using those bits, given the current language.  "Be liberal
in what you receive", etc.

4.1 Same comment about the reserved bits.

4.6 Why is the flag "MAY Encr" when confidentiality is mandatory?

What is the SHLD NOT column?  It's never used in that table.

I don't see the reasoning for some of the settings of that
flag.  For example, I would think that the authentication- and
authorization-related flags would require protection, to guard
against deletion to prevent the operation from taking place,
or to spoof the result.  This also illustrates confusion between
the need for integrity protection vs. confidentiality.  It
would be good to give some general guidance, for the benefit
of people defining Diameter applications.

5.2, search rule 3.2, last paragraph:  Unless I'm misreading something,
it says that the domain suffixes SHOULD and need not match
the original query.

3.3 should probably be numbered 4.

Discuss DNSsec?  What TLS or IPsec certificates should be
checked for?  More specifically:  the peer discovery mechanisms
MUST be tied to a security authorization model.  Each peer to
which a node speaks must be authorized for some role.  The
Diameter implementation must have some list of credentials
that are acceptable *for this role*.  That point should probably
be discussed here, and possibly in the Security section as well.
(Note that suitable checking in this fashion relegates DNSsec
issues to availability, and not even much of that -- an attacker
can't impersonate a legimate peer, because it lacks the right
credentials.) 

5.3 May CER or CEA messages be relayed?

5.3.1 Why is the IP address in the message, when it should be
available via the local incarnation of getpeername()?

5.6.4 What is a "hanging octet"?

6.1.8 Proxy-Info has security implications, and probably requires an
embedded HMAC with a node-local key.

8.3 The RAA message is curious, and perhaps the answer to my
question is in another AAA document.  That said -- in general,
something like a NAS can't do user authentication by itself.
Instead, it's going to use Diameter facilities to send something
upstream.  Ultimately, it's the Diameter server that is going to
make the decision.  That suggests that reauthenticate is more
of a command from the server to the client, where the server
will, at some point, issue a disconnect message.  The current
model seems to suggest a sequence of

server->client: RAR
client->server: authentication info } repeated
server->client: authentication info }
client->server: success/failure

In other words, there's a nested exchange.  Is that intended?
What Session-ID should be used?  Will Diameter implementations
be confused by that sort of sequence?  There's a state machine
lurking in the background here, I think.

9 I'm concerned that I don't see a way for a server to detect
a total ordering of accounting records for a session.  This
would be useful, for example, when processing interim records.
The situation I'm concerned about is as follows.  Suppose a
client sends an interim record to a proxy or relay agent.  The
upstream link from the agent is experiencing a transient
problem.  Or perhaps the agent crashes and reboots, but has
stored the pending records in non-volatile storage.  In the
meantime, the client sends another interim message via another
path, either because it suspects a failure or because it is
using multiple peers for load-sharing.  This second record
can be received first.  I suspect that the easiest solution is
to require that Accounting-Record-Number be monotonically
increasing within a session.

13 Is there some document that discusses the end-to-end (and I mean
that literally here) Diameter authorization model?  I know that
it was discussed in the WG, but I don't see anything on that
here.  What's I'm looking for -- somewhere -- is some discussion
on how, say, a NAS "knows" that it will be paid when an
authorization comes from five proxies away.

14 Non-ascii hyphens (which shouldn't be there anyway)

From: Patrik F�ltstr�m

Text from draft below...

When you have two strings using the Unicode Character Set, there need
to be rules for how you compare the two strings -- if comparison is
done.

Doing bit by bit comparison is cruel, and not recommended, but even if
that is the solution that has to be stated.

The easiest way of doing it is to create a profile of stringprep, which
tells how comparison is to be done, and then point at that profile in
documents like this.

Note: UTF8String in diameter possibly have to be split in two different
types "normalized UTF8String" and "raw UTF8String".

I am happy to explain more if needed.

    paf

>      UTF8String
>          The UTF8String format is derived from the OctetString AVP Base
>          Format. This is a human readable string represented using the
>          ISO/IEC IS 10646-1 character set, encoded as an OctetString
>          using the UTF-8 [UFT8] transformation format described in RFC
>          2279.
>
>          Since additional code points are added by amendments to the
>          10646 standard from time to time, implementations MUST be
>          prepared to encounter any code point from 0x00000001 to
>          0x7fffffff. Byte sequences that do not correspond to the valid
>          encoding of a code point into UTF-8 charset or are outside
> this
>          range are prohibited.
>
>          The use of control codes SHOULD be avoided. When it is
>          necessary to represent a newline, the control code sequence CR
>          LF SHOULD be used.
>
>          The use of leading or trailing white space SHOULD be avoided.
>
>          For code points not directly supported by user interface
>          hardware or software, an alternative means of entry and
>          display, such as hexadecimal, MAY be provided.
>
>          For information encoded in 7-bit US-ASCII, the UTF-8 charset
> is
>          identical to the US-ASCII charset.
>
>          UTF-8 may require multiple bytes to represent a single
>          character / code point; thus the length of an UTF8String in
>          octets may be different from the number of characters encoded.
>
>          Note that the AVP Length field of an UTF8String is measured in
>          octets, not characters.


From: Patrik F�ltstr�m

> The easiest way of doing it is to create a profile of stringprep,
> which tells how comparison is to be done, and then point at that
> profile in documents like this.

I.e. suggested action:

  1) Create a profile of stringprep to be used for diameter
  2) Add the following text to "UTF8String", after first paragraph

The string is to be normalized according to the specification in RFC
XXXX [xxxx]

  3) Add reference to the profile

Reference:

[xxxx] RFC XXXX, stringprep profile for use in the Diameter protocol.