Subject: (radius) Tagged attribute question

From: "Darran Potter" <[email-masked]>
Date: Fri, 9 Apr 1999 17:09:57 +0100

When the Tunneling RFC states "If the Tag field is unused, it MUST be zero."
what does it actually mean by "unused"?

I assume it means "Radius Servers that dont allow more than one tunnel
configuration per user profile"

Any system that allows multiple tunnels will probably default to tag=1 when
only one tag has been configured - even if the user didnt configure the
Tunnel-Preference.

Darran

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Barney Wolff <[email-masked]>
Date: Wed, 14 Apr 1999 14:14 EDT

But there was never any possibility that the salt could be mistaken for
a tag.  Consider: the length of the string portion of the attribute must
always be a multiple of 16, the length of the salt is fixed at 2, and the
tag is fixed at 1.  So if the low-order 4 bits of the length byte of the
attribute is 0010, neither tag nor salt is present; if 0011, tag is
present but salt is not; if 0100, salt is present and tag is not; if
0101, both tag and salt are present; all other values are bogus.

The other way to look at the issue is to say that Tunnel-Password is a
fixed-length attribute (actually, fixed + N*16) and the way to indicate
absence of a tag in a fixed-length attribute is to make the byte zero.
As zero is not a valid tag value, it should not be mistaken for a tag.

Seems to me that a sensible (ie, liberal) attribute receiver should be
prepared for either case.

I don't quite get what specifically you're objecting to - I did NOT say
that tag=0 in a string attribute should denote no-tag, only that Tunnel-
Password should work like an integer attribute, not like a string, in
what the sender SHOULD do.  As above, I believe the receiver SHOULD take
it either way.

I don't think Tunnel-Password has ever been defined without the tag byte
in any draft - so, "backward compatible" to what?

Barney Wolff  <[email-masked]>

> From: Aydin Edguer <[email-masked]>
> Subject: Re: (radius) Tagged attribute question
> To: [email-masked]
> Date: Wed, 14 Apr 1999 13:46:47 -0400 (EDT)
> Content-Length: 969
> Reply-To: Aydin Edguer <[email-masked]>
> 
> > > But if we're going to say the tag byte should always be present in Tunnel-
> > > Password, we should make it zero when not used.
> > 
> > OK.
> 
> No!  Please don't!!  The whole point behind the "no tags" is backwards
> compatibility.  If an implementation does not support tags at all, then
> the attributes should have no tag field.  For an integer attribute,
> this would make that the location in the attribute, where the TAG would
> normally reside, have a value of zero.  For a string attribute, it would
> be the first octet of the string.
> 
> If an implementation supports tags then it must use a valid non-zero
> value for the tag - 0x01 - 0x1F.  Any values outside this range are
> used to denote the lag of TAG support.  This is the reason why the
> most significant bit (leftmost) of the Salt field MUST be set (1).
> It guarantees that a salt cannot be mistaken for a TAG.
> -
-

---

From: Aydin Edguer <[email-masked]>
Date: Wed, 14 Apr 1999 18:10:54 -0400 (EDT)

> My understanding of Barney's proposal was that if the Tag field is always
> present in the Tunnel-Password Attribute, just say it's zero if not used.
> This seems to be reasonable.  Are people treating the Tag field the same in
> Tunnel-Password as in integer attributes (i.e., it disappears)?

Yes.  When sending the Tunnel-Password attribute, when the TAG field is not
supported, then the Tag field completely disappears and becomes the first
octet of the Salt field.  This is the reason for the explicit statement
about the Salt field value that you previously added to the draft.  Perhaps
the disagreement is coming over the meaning of the term "unused".

Case 1: TAGs are not supported and will not be used.

  The appearance of an integer attribute:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Value (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The appearance of a string attribute:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |        String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The appearance of a salted attribute:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Salt                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Case 2: TAGs *are* supported and but no TAG has been defined.

  In this case, it appears that the request is to add 0x00 to the list
  of valid Tags (e.g., to not limit it to be 0x01 through 0x1F).  In 
  my opinion, the reason for the disallowing the 0x00 Tag was so that
  when you get an integer datatype attribute, you can immediately know
  whether the sending system supports tags or not.  If you force the
  default to be one, when no Tag has been defined in the user file,
  but Tags, then it is immediately apparent.
  I can live with adding zero as a special case Tag value which can
  be used, but I want it to be clear that if the server does not support
  Tags that there does not have to be a tag field of zero in the
  Tunnel-Password or in any string datatype attribute (like
  Tunnel-Server-Endpoint).

  The appearance of an integer attribute:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      Tag      |    Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The appearance of a string attribute:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |    String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The appearance of a salted attribute:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |    Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Case 3: TAGs *are* supported and but a TAG has been defined in the profile.

  The appearance of an integer attribute:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |    Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The appearance of a string attribute:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |    String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The appearance of a salted attribute:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |    Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.