Subject: 10.4 IDENTIFY Command II

From: [email-masked]
Date: Wed, 6 Nov 2002 18:50:58 -0500

I hate it when I get distracted and forget to complete an email before 
sending.  Sorry to split the issue on this section into 2 emails but...

There is a discrepancy in the ABNF for identifyparam compared to the text 
and examples.  The ABNF is:

        identifyparam   = *(

                        ; the following are optional,
                        ; but MUST NOT occur more than once

                          id-param
                        / localize-param
                        / latency-param

                        ; the following MUST occur exactly once and only
                        ; when the latency-param has been supplied and
                        ; MUST NOT be supplied if the latency-param is
                        ; not supplied.

                        / action-param

                        ; the following is optional,
                        ; and MAY occur more than once

                        / (";" xparam)

                        ; The value is the UPN of the requested
                        ; identity. If not supplied it is a request
                        ; to return to the original authenticated 
identity.

                        / option-param upn

                        )
[Snip, snip]
      And for the CUA to return to its original authenticated identity
      the OPTIONS parameter is omitted:

Alas the ABNF does NOT accurately reflect that option-param is truely 
optional.  For this the line needs to be changed to the following to allow 
what the cited text above suggests:

                        ; The value is the UPN of the requested
                        ; identity. If not supplied it is a request
                        ; to return to the original authenticated 
identity.

                        / [ option-param ] upn

Lastly, the behaviour for when an IDENTITY fails is unclear.  The text 
simply says:

   If they do, the session assumes the new identity,
   otherwise a security error is returned.

but does not expressly indicate that the original (or previous) identity 
is to be resumed.  It could be that more than one IDENTITY command has 
been issued with some that worked.  As such its unclear if the failure 
results in the last 'confirmed' or allowed identity to be used or if the 
original authentication identity is to be restored.  I dont care either 
way, I just want consistant behaviour.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 06 Nov 2002 18:06:37 -0700

[email-masked] wrote:

> optional.  For this the line needs to be changed to the following to 
> allow what the cited text above suggests:
> 
>                        ; to return to the original authenticated identity.
> 
>                        / [ option-param ] upn

Your right there is an error, however it would be:
	
                    ; The value is the UPN of the requested
                    ; identity. If not supplied it is a request
                    ; to return to the original authenticated identity.
                    ; The following MUST occur exactly once and only
                    ; when the CU wished to change to another UPN.
                    ; The following would not be supplied if the
                    ; CU wished to switch to their original identity.

                    /  option-param upn

Your ABNF would make it:

		CMDnew-upn-id:IDENTITY

Where it should be this to ask to switch back to your original identity:

		CMD:IDENTITY

Or to ask to switch to another identity:

		CMD;OPTIONS=new-upn-id:IDENTITY

> been issued with some that worked.

Please point to the section of CAP that says that you can
send more than one IDENTITY command at a time. Or please
point to the section of CAP that says you can send more than
one CMD at a time.

> As such its unclear if the failure 

What does 'otherwise' mean to you?

-- 
-
Doug Royer                       Work: (208)612-INET
[email-masked]                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

---

From: Andrea Campi <[email-masked]>
Date: Fri, 8 Nov 2002 14:59:59 +0100

>    otherwise a security error is returned.

By the way, I would like to propose that we change this so that
IDENTIFY only affects the channel it is sent on, not the whole session.

This would be beneficial for several reasons (such as accessing
different targets with different credentials), but above all it
would remove ambiguity. Otherwise, if you have ongoing traffic on
other channels, what happens? When do the new credentials take
effect?

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: [email-masked]
Date: Mon, 11 Nov 2002 11:45:36 -0500

>                     ; CU wished to switch to their original identity.

This newer ABNF does NOT make it clear that option-param AND the related 
UPN are either MUST or not at all (to get that "CU wished to switch to 
their original identity.")  You need to make that entire line a "0 or 1" 
instance then.  The comment in the ABNF does not transcode to the actual 
ABNF thats verifiable otherwise.

>       CMDnew-upn-id:IDENTITY

A related change I posted was that there is NO cmd-specific for any 
commands.  The UPN in this case _is_ that cmd-specific and it should be 
noted as such (see other thread).  As such, the UPN _could_not_ appear as 
you suggested since its the cmd-specific of the IDENTIFY command.  Mea 
culpa for not linking the two in this post, sorry.

>       CMD;OPTIONS=new-upn-id:IDENTITY

<SIDENOTE>
This is not a valid example as the new-upn-id is NOT valid per the 
definition of allowable UPNs in 1.3 Definitions:

   User Principal Name (UPN) -  A unique identifier that denotes a CU or
      a group of CU.  A UPN is a RFC 822 compliant email address, with
      exceptions listed below, and in most cases it is deliverable to
      the CU.  In some cases it is identical to the CU's well known
      email address.  A CU's UPN MUST never be an e-mail address that is
      deliverable to a different person as there is no requirement that
      a person's UPN MUST BE their e-mail address.  A UPN is formatted
      as a user name followed by "@" followed by a Realm in the form of
      a valid, and unique, DNS domain name.  The user name MUST BE
      unique within the Realm.  In  it's simplest form it looks like
      "[email-masked]".

      In certain cases a UPN will not be RFC 822 compliant.  When
      anonymous authentication is used, or anonymous authorization is
      being defined, the special UPN "@" will be used.  When
      authentication MUST BE used, but unique identity MUST BE obscured,
      a UPN of the form @DNS-domain-name may be used.  For example,
      "@example.com".

The example used is just the username part of the UPN and not the full 
UPN.  Please make sure all examples have properly formed UPNs in the draft 
for those that only code by example...
</SIDENOTE>

> send more than one IDENTITY command at a time. 

1: I can pipleine several commands at a time so its perfectly valid (and 
probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY) 
command at a time.

2: I did not say I sent them _concurrently_.  My groups AA may need to 
change identities often based on requests from people in my group (as well 
as having to do her own C&S).  No place in the draft does it say that a CU 
MUST change back to their initial identity before changing into another so 
its perfectly valid for her to change from herself to my boss and then to 
me and then to another person.

My point is that its 100% unspecified what identity is 'active' if an 
IDENTIFY fails!  Does it revert to the last one that was in use?  To the 
initial one?  None? Flip a coin and pick one??...

>                                                  Or please

Thats the purpose of the id-param, so you can pipeline cmds and be able to 
match responses to multiple concurrent commands (among other things):

   id-param         = ";" "ID" "=" unique-id
                    ; The text value supplied is a unique value
                    ; shared between the CUA and CS to uniquely
                    ; identify the instance of command in the
                    ; the current CUA session. The value has
                    ; no meaning to other CUAs or other sessions.

> What does 'otherwise' mean to you?

The full sentence is:

So the CUA knows that it was rejected, that part I grok.  It does not know 
what identity if is now effectively using though.  Or did I just overlook 
that part? 

CAP should expressly declare what identity the CUA now is using on a 
failure besides just saying the CS rejects it.  None?  The last accepted 
one (in the AA case above...)?  The original one?   Anonymous?  In order 
to properly make different CUAs and CSs interoperate CAP should be clear 
on this point.  Making an assumption is a BAD idea...

Bruce

---

From: [email-masked]
Date: Mon, 11 Nov 2002 13:31:41 -0500

> IDENTIFY only affects the channel it is sent on, not the whole session.

Are you talking about a BEEP session or a CAP session?  It sounds as if 
you are referring to the BEEP session since currently a CAP session is 
just a BEEP channel:

   CAP Session -  An open communication channel between a CUA and a
      Calendar Server.  If the CAP session is authenticated, the CU is
      "authenticated" and it is an "authenticated CAP session".

so establishing another BEEP channel would cause a new CAP session to be 
created on the current BEEP session.  This does not sound to be too 
expensive to do say compared to creating the actual BEEP session... 

Actually the definition does not expressly say its a "BEEP channel" 
between the CUA and CS so this could be read as a being a single network 
connection ala TCPIP socket connection.  Is it an incorrect assumption to 
read "BEEP session" or "BEEP channel" in place of "communcation channel"? 
If so, whats the linkage between "communication channel" and CAP/BEEP?  If 
not, can we clean up the text a bit here?

If you are referring to a CAP session instead of a BEEP session then don't 
read further as Im basing the rest on this assumption.

Do we want to add the complexity of multiple identities per CAP 
session/BEEP channel?  Why wouldn't we just use a new BEEP channel to 
establish a new CAP session?  That way any failure would result in that 
channel being closed instead of all CAP sessions/BEEP channels.

Along the same lines of thought, which session is this text referring to:

   IDENTIFY -  Set a new identity for the session.  Initiated by the CUA
      only.  (Section 10.4)

I assume its a CAP session (aka BEEP channel) but its not clear.  Doug?

There is some text about terminating the BEEP session instead of the CAP 
session that directly relates to your response:

   If a CS considers the "IDENTIFY" command an attempt to violate
   security, the CS MAY terminate the BEEP session without any further
   notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply.

In this case it expressly states that its the BEEP session in question 
rather than the CAP session.  Being a BEEP novice Im not sure if its 
proper/safe to use the two terms interchangably.  Perhaps Marshal can help 
out here...  This text makes the CS drop all the CAP sessions if the 
IDENTIFY command fails on any CAP session/BEEP channel.  Kind of a harsh 
response to a single failure at least in my mind.  This is appropriate for 
DOS attacks or stopping hacking but its a bit strong for the simple case 
where the CS and CUA disagree on what identities an AA can actually 
assume.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Nov 2002 12:18:04 -0700

> ABNF thats verifiable otherwise.

There is no way in ABNF to say when parameters may exist. It is always
described in text. ABNF restricts the data to a specific set, but it
can not without extra text describe it usage.

> UPN.  Please make sure all examples have properly formed UPNs in the 
> draft for those that only code by example...

Which example is a 'username' ?

> probably a good way to attack a CS) to send > 1 IDENTIFY (not IDENTITY) 

So do you agree with (who ever sent it) that IDENTIFY is channel specific?

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Nov 2002 12:50:28 -0700

> you are referring to the BEEP session since currently a CAP session is 

In section 4. of BEEP

    "Whenever a successful authentication occurs, on any channel, the
    authenticated identity is updated for all existing and future
    channels on the BEEP session; further, no additional attempts at
    authentication are allowed."

So - you can only authenticate once per BEEP session.

So the question to answer is: does the CAP IDENTIFY command
effect one channel - or is it global?

If global - then maybe we need to add something to CAP like:

		The new identity takes effect after pending commands complete
		from the CS's point of view and the identity does not change
		in the middle of executing a command. The new identity
		only effects new commands issued by the CUA and after
                 receiving an IDENTIFY success reply code (x.x) from the CS.

If per channel - then we need to add text like:

		An IDENTIFY command is per BEEP channel. The IDENTIFY
		command does not effect other channels. The new identity
		only effects new commands issued by the CUA and after
                 receiving an IDENTIFY success reply code (x.x) from the CS
		on that channel.

 > IDENTIFY command fails on any CAP session/BEEP channel.

No that is not what it says. It does NOT say 'if the IDENTIFY command
fails...', it says 'If a CS considers the "IDENTIFY" command an attempt to
violate  security...'.

And I agree.

 >  Kind of a harsh  response to a single failure at least in my mind.

Please point to the text that says 'a single failure' causes the BEEP
session to be terminated when the IDENTIFY command fails.

 > This is appropriate for
 > where the CS and CUA disagree on what identities an AA can actually assume.

--

---

From: [email-masked]
Date: Tue, 12 Nov 2002 10:57:40 -0500

> can not without extra text describe it usage.

Wrong, it just takes some changing to the ABNF to do this.  For example, 
instead of:

        identifyparam   = *(
[Snip, snip]
                        / option-param upn
                        )

You can fix this to be correct using, say:

        identifyparam   = *(
[Snip, snip]
                        / [ option-param ]

        cmd-specific     =/ upn 
                            ; The option-param cmd-specific value for 
IDENTIFY
                            ; is a UPN.

This now correctly indicates that option-param on IDENTIFY is either there 
once or not at all.  It also correctly indicates that cmd-specific for 
this command is a UPN (see RFC 2234, Section 3.3 Incremental Alternatives 
if this notation is unclear to you or go check 2445 where it was used.)

> Which example is a 'username' ?

<DIGRESSION>
The cmd-specific value in your last example (left in above) is just 
new-upn-id.  By the defintion of UPN composition in Section 1.3 of all the 
drafts I checked the format of the UPN is basically: "username" '@' 
"realm".  As such just how does one parse the "new-upn-id" as a valid UPN? 
 Its got to be the username component OR the realm component.  HOWEVER 
your definiton in Section 1.3 does NOT allow just those parts by 
themselves!  Hence, the example is malformed.  The example should be 
something like:

CMD;OPTIONS=new-upn-id@some-realm:IDENTITY

or you need to change the clear definition of UPN composition in 1.3 to be 
less accurate/clear.
</DIGRESSION>

> So do you agree with (who ever sent it) that IDENTIFY is channel 
specific?

I havent seen anything that would preclude me from sending multiple 
IDENTIFY commands on the same channel.  Then again I keep chasing drafts 
so I could have overlooked it.  Where is that restriction in the 
09-submitted draft?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Nov 2002 10:56:50 -0700

> new-upn-id.  By the defintion of UPN composition in Section 1.3 of all 
> the drafts I checked the format of the UPN is basically: "username" '@' 
> "realm".  As such just how does one parse the "new-upn-id" as a valid 
> UPN?  Its got to be the username component OR the realm component. 
>  HOWEVER your definiton in Section 1.3 does NOT allow just those parts 
> by themselves!  Hence, the example is malformed.  The example should be 
> something like:
> 

You are joking right?

> or you need to change the clear definition of UPN composition in 1.3 to 
> be less accurate/clear.
> </DIGRESSION>
> 

You can not send more that one command at a time on the same channel - a BEEP 
restriction. So yes you can send IDENTIFY commands all day as long
on the same channel as you only send one command at a time. The CS will or
will error out on each one as received.

--

---

From: [email-masked]
Date: Tue, 12 Nov 2002 13:15:17 -0500

> effect one channel - or is it global?

The more useful scenario is one per channel.  That would allow an AA or 
proxy to maintain their own identity on one channel and open up as many 
other channels as necessary to do work on potentially several other CUs at 
the same time.  Then they can act as themselves on their own channel and 
concurrently act on my behalf on another (and on my boses behalf on 
another and...).

This does seem to negate the need to do multiple identity changes on a 
channel though.  All that they would need to be able to do is open a new 
BEEP channel, change the identity once and then when done close the 
channel.  If they needed to become a different identity they could simply 
open a new channel.  Since they should already have a channel open for 
their principal identity there is not a pressing need to be able to revert 
back to it on the subsequently created channels.  We could simplify CAP 
and IDENTIFY a bit by expressly modelling this and precluding multiple 
IDENTIFY commands on a channel...

>                  receiving an IDENTIFY success reply code (x.x) from the 
CS

That works.  Given this do we want to allow multiple IDENTIFY commands per 
channel or not??  Im all for not allowing them but if making a new BEEP 
channel is an expensive operation then maybe we do want to allow it...

> fails...', it says 'If a CS considers the "IDENTIFY" command an attempt 
to

So even if the IDENTIFY is a success the CS could "consider the "IDENTIFY" 
command an attempt to violate security" and shut down my BEEP session 
"without any further notice" so I have no clue why the hell the CS just 
punted me for doing an IDENTIFY command that I should be able to do...???  
Id love to hear the Tech Support call on that one.  (Making this 
determination is an implementation issue and thus falls under 
Administration or Configuration which is OOB for CAP 1.0 but the CAP 1.0 
does not distinguish between this happening for failure cases only which 
is where I think it should and any possible case...)

> And I agree.

If the draft clearly stated that such a determination was for failure 
cases then I would agree too.  Currently it does not.  As such some CS 
could have a policy that says "5 IDENTIFY commands w/in 1 minute may be a 
hacker so drop them" then its possible that my efficient team AA could 
accidentally trip this and get punted from the CS w/o warning or notice 
for using IDENTIFY to put a team meeting on all of our calendars.  Poor 
design IMHO.

> session to be terminated when the IDENTIFY command fails.

The determination of how the CS "considers the "IDENTIFY" command an 
attempt to violate security" is vague enough that its possible that a 
single failure could cause the termination of the BEEP session "without 
any further notice".  The draft does not preclude it so it is possible; 
hence _my_ comment.  While this determination is TBD (ie: Administrative) 
my point is that this determination should only happen on failure cases 
instead of either success OR failure.

Bruce

---

From: [email-masked]
Date: Tue, 12 Nov 2002 10:57:40 -0500

identifyparam   = *(
[Snip, snip]
                        / option-param upn
                        )

        identifyparam   = *(
[Snip, snip]
                        / [ option-param ]

        cmd-specific     =/ upn 

<DIGRESSION>

Bruce

---

From: [email-masked]
Date: Wed, 13 Nov 2002 12:07:40 -0500

[Snip, snip]
> > CMD;OPTIONS=new-upn-id@some-realm:IDENTITY

Actually no Im not.  I should have used "@some-realm.org" actually so 
sorry about that.  Here is the UPN definition in Section 1.3 of the 
09-submitted:

[Emphasis added].  As such the UPN in your example (and the one in Section 
10.4) are incorrect; the UPN used does not adhere to the defintion of UPN 
formatting.    (Your example does not adhere to the 2 exceptions in the 
last paragraph that I can see either.)

Unless there is some way to parse "new-upn-id" into the UPN components of 
Usern ame and Realm that Im just missing, the example you gave originally 
AND those in the draft are incorrect...

> You can not send more that one command at a time on the same channel- a 
BEEP 
> restriction. 

Huh?  No it does not.  From RFC 3080:

2.6 Asynchrony

   BEEP accommodates asynchronous interactions, both within a single
   channel and between separate channels.  This feature allows
   pipelining (intra-channel) and parallelism (inter-channel).

2.6.1 Within a Single Channel

   A BEEP peer acting in the client role may send multiple "MSG"
   messages on the same channel without waiting to receive the
   corresponding replies.  This provides pipelining within a single
   channel.

I see that it is possible to "send multiple "MSG" messages on the same 
channel" so I dont know where you got that idea from.  Each MSG contains a 
new command so I can send multiple IDENTIFY command so this is perhaps 
what you are thinking about.  However, BEEP has NO say in what the 
contents of CAPs payload are since CAP is newer than BEEP and BEEP does 
NOT put any kind of "only 1 command" restriction on any BEEP based 
payload.  Also I see NOTHING in CAP 09-b-2, 09-b-3 or 09-submitted that 
says that the IDENTIFY command MUST be the only command sent in the single 
payload.

We went over this > 1 "VCALENDAR" in a single MIME stream discussion 
w/John not 3 months ago and you agreed that 2445 allows for:

BEGIN:VCALENDAR
...
END:VCALENDAR
BEGIN:VCALENDAR
...
END:VCALENDAR

kinds of data.  As such I can legally send 2 CMD:IDENTIFY blocks in the 
same payload.

The solution: Expressly preclude it in the next CAP draft.  That is, "Only 
1 outstanding IDENTIFY command is permitted per CAP session regardless of 
the number of channels in use." or some other such language.  Use BEEPs "
security layer negotiation" stuff as a kind of model for this text.

Refocusing on the real stuff:

Despite all this traffic I still see no argument so far why the CS should 
_NOT_  send back the list of UPNs that the CUA may use on any IDENTIFY 
command.  There are good reasons to put the removed ability to get the 
UPNs from the CS back into CAP so I would like to see that done for the 
next draft (or interim release).

Reading the list from the CS is not an administrative feature and that 
data directly relates to the use of the IDENTIFY command so why is it not 
in the spec?

Bruce

---

From: [email-masked]
Date: Wed, 13 Nov 2002 12:13:45 -0500

BEEP 
> will error out on each one as received.

Which is a better approach to take:

1: Make the CUA guess at what UPNs a CS will allow it to assume and risk 
getting the session terminated or generating extra network traffic, etc OR

2: Allow the CUA to get the list of allowed UPNs from the CS so that a 
single command can be issued (if allowed) w/o fear of seemingly arbitrary 
rejection

I think #2 is the better approach for a new protocol.  What about everyone 
else?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Nov 2002 10:27:53 -0700

> 
> That works.  Given this do we want to allow multiple IDENTIFY commands 
> per channel or not??  Im all for not allowing them but if making a new 
> BEEP channel is an expensive operation then maybe we do want to allow it...

I do not think it makes any differance as a CUA could go from the
original to I-1, back to the original, then to I-2, ... anyway
on the same channel.

> So even if the IDENTIFY is a success the CS could "consider the 
> "IDENTIFY" command an attempt to violate security" and shut down my BEEP 
> session "without any further notice" so I have no clue why the hell the 
> CS just punted me for doing an IDENTIFY command that I should be able to 
> do...??? 

Feel free to implement your security that way - I will not be doing that.
I feel that other will not do that. However if your implementations
considers that a security violation, then this current wording makes
it work for both of us and in a compatible way.

I for one do not need permission from a specification to terminate
a connection without notice for a whatever I consider a security
violation.

>  Id love to hear the Tech Support call on that one.  (Making 
> this determination is an implementation issue and thus falls under 
> .
> could have a policy that says "5 IDENTIFY commands w/in 1 minute may be 
> a hacker so drop them" then its possible that my efficient team AA could 

I think the current wording is correct. It is NOT per failure, it is
for when the implementation considers it a security violation. If a
specific implementation hangs up on your CUA without notice, call
the owner of the CS or go to another vendor, ISP, or whatever.

> any further notice".

Again - if your implementaion considers that a security violation, I would
expect it to terminate the connection.

I might consider any attempt to become the 'root' user a security violation
when the connection from from the WAN and not the LAN and hang up on
the first failure. Or I might not depending on the installation.

--

---

From: Andrea Campi <[email-masked]>
Date: Thu, 14 Nov 2002 20:21:34 +0100

> So - you can only authenticate once per BEEP session.

Agreed (and this is correct from a security point of view).

>                 receiving an IDENTIFY success reply code (x.x) from the CS

Yes please; also Bruce seems to be in agreement.

> fails...', it says 'If a CS considers the "IDENTIFY" command an attempt to

What about:

If a CS detects a sequence of failures in response to one or more
"IDENTIFY" commands it considers an attempt to violate security,
the CS MAY terminate the BEEP session without any further
notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply.
It is a good idea to trigger this behavior after n failures.

Does this satisfy everybody? Bruce, note that you are still
guaranteed to get a REQUEST-STATUS. We could even state more
explicitely:

The REQUEST-STATUS value SHOULD indicate this is a security
violation disconnection.

What do you say?

Bye,
	Andrea

---

From: [email-masked]
Date: Mon, 18 Nov 2002 11:49:28 -0500

> it work for both of us and in a compatible way.

I dislike the design that basically cuts me off from the CS (yours or 
mine) w/o any notice even if a command succeeds.  Kinda illogical to me. 
If the command succeeded then I should be allowed in.  If it failed then I 
should be told so in order to take some appropriate action or logging 
action.

The CS should _at_least_ send back some info before slamming the entire 
BEEP session.  Otherwise the CUA has NO way to determine why the 
connection to the CS was lost:

1: Network failure
2: CS crash/shutdown
3: "Im a bad boy"
4: "Im not allowed to be the CFO of the company"
5: "Sorry C&S Team AA, you are still not allowed to assume Bruces 
identity"
...

Knowing _why_ allows me to build a more robust CUA.  Also, the CAP design 
precludes my CS from sending back some helpful info before dropping the 
connection.  It therefore makes it impossible for me to build a friendlier 
CS/CUA interaction for the failure case.  I think this should be 
allowed/encouraged.  After all BEEP encourages the logging of diagnostic 
entries/info in failure cases so why dont we allow it?

> a connection without notice for a whatever I consider a security

So just how would you craft your awesome CUA so that it can distinguish 
between the cases listed above??  I dont see anything in the CAP draft 
that would allow it so you must have some pretty good mojo to do it w/o 
protocol support...
 
> the owner of the CS or go to another vendor, ISP, or whatever.

You are assuming that the CS did some diagnostic logging at a minimum. 
That BEEP-like recomendation should be added to the draft since its not 
there now.

Besides, only the admin of the CS may be able to help with the case I 
described.  The vendor would be of no help unless they are hosting it for 
you.  One thing to keep in mind in "Enterprise" environements or ISP sites 
is that the "Help Desk" folks are rarely the actual server admins and 
there is not always a simple linkage between the two.  As such its not 
always a matter of a simple call gets you resolved quickly...

Im NOT trying to nail down what criteria a CS uses to determine if the 
IDENTIFY command is an actual violation or not; Im just trying to nail 
down the behaviour so that its a bit more robust and allows for providing 
of diagnostic information when/if the implementation desires to send it.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 18 Nov 2002 10:26:47 -0700

[email-masked] wrote:
> mine) w/o any notice even if a command succeeds.

Do you feel that 'security violation' == 'succeeds?  I do not.

>  Kinda illogical to me. 
>  If the command succeeded then I should be allowed in. 

Where does the draft say that if it succeeds that you are not allowed in?

 > If it failed
> then I should be told so in order to take some appropriate action or 
> logging action

> connection to the CS was lost:

If you determined that a hacker was attacking your system, would
you first inform them:

	> 5: "Sorry C&S Team AA, you are still not allowed to assume Bruces identity"
	> ...

Or would you just block them? I block them and let them wonder why they
failed. I would not inform them of the specifics. And we are talking
about a 'security violation' and NOT a failed login attempt.

> Knowing _why_ allows me to build a more robust CUA.  Also, the CAP 
> design precludes my CS from sending back some helpful info before 
> dropping the connection.  It therefore makes it impossible for me to 
> build a friendlier CS/CUA interaction for the failure case.  I think 
> this should be allowed/encouraged.  After all BEEP encourages the 
> logging of diagnostic entries/info in failure cases so why dont we allow 
> it?
> 

If a CUA attempts to hack my system - I would not care about the error
messages it displayed.

>  That BEEP-like recomendation should be added to the draft since its not 

Where does it say that the CS may not perform logging as specified
and recommended in BEEP?

> described.  The vendor would be of no help unless they are hosting it 
> for you.  One thing to keep in mind in "Enterprise" environements or ISP 
> sites is that the "Help Desk" folks are rarely the actual server admins 
> and there is not always a simple linkage between the two.  As such its 
> not always a matter of a simple call gets you resolved quickly...

Yes - I will also log failures and security violations.

> down the behaviour so that its a bit more robust and allows for 
> providing of diagnostic information when/if the implementation desires 
> to send it.

I will never tell a hacker or malicious software why attempts failed.

--

---

From: Andrea Campi <[email-masked]>
Date: Mon, 18 Nov 2002 19:33:41 +0100

Hi Doug,

> If you determined that a hacker was attacking your system, would
[...]
> about a 'security violation' and NOT a failed login attempt.

The current text still says:

I interpret this as mandating a failure message, even if a generic
one. If I am missing something, could you please send an example
conversation showing what happens (with BEEP layer if needed)?

The more I think about it, the more I think an explicit BYE command
would be beneficial.

Bye,
	Andrea

---

From: [email-masked]
Date: Mon, 18 Nov 2002 14:09:07 -0500

> Yes please; also Bruce seems to be in agreement.

Sure.

> The REQUEST-STATUS value SHOULD indicate this is a security

This sound good to me (the last statment is a bonus really but I dont 
mind).  The biggest concern I have is the no response back rather than the 
actual "_when_ does it happen" question.

Bruce