Subject: Re: IESG feedback on core drafts.

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 13 Mar 2003 12:45:55 -0700

Well, I'm not sure if this is what we need or not, but
here is my first stab--

Here is the current Security Considerations section from
the transport draft.

>   This protocol provides a secure encrypted channel over an insecure
>   network.  It performs server host authentication, key exchange,
>   encryption, and integrity protection.  It also derives a unique
>   session id that may be used by higher-level protocols.
>
>   It is expected that this protocol will sometimes be used without
>   insisting on reliable association between the server host key and the
>   server host name.  Such use is inherently insecure, but may be
>   necessary in non-security critical environments, and still provides
>   protection against passive attacks.  However, implementors of
>   protocols running on top of this protocol should keep this
>   possibility in mind.
>
>   This protocol is designed to be used over a reliable transport.  If
>   transmission errors or message manipulation occur, the connection is
>   closed.  The connection SHOULD be re-established if this occurs.
>   Denial of service attacks of this type ("wire cutter") are almost
>   impossible to avoid.
>
>   The protocol was not designed to eliminate covert channels.  For
>   example, the padding, SSH_MSG_IGNORE messages, and several other
>   places in the protocol can be used to pass covert information, and
>   the recipient has no reliable way to verify whether such information
>   is being sent.

Here is my proposed revision:

11. Security Considerations

   This protocol provides a secure encrypted channel over an insecure
   network.  It performs server host authentication, key exchange,
   encryption, and integrity protection.  It also derives a unique
   session id that may be used by higher-level protocols.

11.1 Confidentiality 

   This protocol does allow the encryption mechanism to be
   disabled.  Implementors SHOULD be wary of exposing this
   feature for any purpose other than debugging.  Users and
   administrators SHOULD be explicitly warned anytime the
   "none" method is enabled.
   
   So long as the "none" cipher is not used, this protocol
   provides confidentiality.  Older, smaller ciphers, such
   as 3des and arcfour MAY be less secure from attack than
   ciphers such as AES.  Implementors SHOULD prefer ciphers
   such as twofish, serpent, or AES over blowfish, 3des and
   arcfour.

11.2 Data Integrity

   This protocol does allow the Data Integrity mechanism to
   be disabled.  Implementors SHOULD be wary of exposing this
   feature for any purpose other than debugging.  Users and
   administrators SHOULD be explicitly warned anytime the
   "none" mac is enabled.
   
   So long as the "none" mac is not used, this protocol
   provides data integrity.

11.3 Replay

   This protocol binds each session key to the session
   by including random data that is specific to the
   session in the hash used to produce session keys.

   This session id is used by higher level protocols
   to prevent replay of packets form previous sessions.

   In addition, the use of cipher chaining prevents
   replay of packets within the session.  Cipher chaining
   also prevents the insertion or deletion of packets.

11.4 Man-in-the-middle

   This protocol makes no assumptions nor provisions for
   an infrastructure for distributing public keys.  It is
   expected that this protocol will sometimes be used without
   insisting on reliable association between the server host
   key and the server host name.  Such usage is vulnerable
   to man-in-the-middle attacks.

   This vulnerability to man-in-the-middle attacks can
   be mitigated in several fashions:

   1. Narrow the window.  If the client ensures that the
      host key for a given server remains consistant, an
      attacker must execute the man-in-the-middle attack
      on the _first_ connection to a given server.

   2. Use an authentication method that is not vulnerable
      to man-in-the-middle.  For example, public-key
      authentication is not vulnerable to man-in-the-middle
      attack, because the signature is made across data
      that is session specific.  The attack can not use
      the signature he receives because the session specific
      data between the attacker and server is different, and
      can not create a valid signature because he does not
      have the private key.

   3. Because the protocol is extensible, future extensions
      to the protocol may provide better mechanisms for dealing
      with the need to know the server's host key before
      connecting.  For example, storing the hostkey fingerprint
      in a secure dns database, or using kerberos over gssapi
      during keyexchange to authenticate the server.
   
   Use of this protocol without reliable association
   is inherently insecure, but may be necessary in
   non-security critical environments, and still
   provides protection against passive attacks.  However,
   implementors of protocols running on top of this
   protocol should keep this possibility in mind.

11.5 Denial-of-service

   This protocol is designed to be used over a reliable transport.  If
   transmission errors or message manipulation occur, the connection is
   closed.  The connection SHOULD be re-established if this occurs.
   Denial of service attacks of this type ("wire cutter") are almost
   impossible to avoid.

   In addition, this protocol is vulnerable to Denial of Service
   attack because an attacker can force the server to go through
   the CPU and memory intensive tasks of connection setup and
   key exchange without authenticating.  Implementors SHOULD provide
   features that make this more difficult.  For example, only allowing
   connections from a subset of IPs known to have valid users.
  
11.6 Covert Channels

   The protocol was not designed to eliminate covert channels.  For
   example, the padding, SSH_MSG_IGNORE messages, and several other
   places in the protocol can be used to pass covert information, and
   the recipient has no reliable way to verify whether such information
   is being sent.

----

Is this what is needed, or am I way off track?

Thanks,

Joseph

----- Original Message ----- 
From: "Bill Sommerfeld" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, February 20, 2003 19:12
Subject: IESG feedback on core drafts.

> Some time ago I mentioned that the core drafts were being held up due
> to concerns about the security considerations section.
> 
> I've just gotten feedback from Steve Bellovin (security co-AD).
> 
> He states that in his opinion, the security consideration section is
> inadequate and should be rewritten along the lines described in
> draft-iab-sec-cons-03.txt including:
> 
>     ".. a discussion of the limitations of the protocol, the
>     countermeasures, and the residual vulnerabilities.  Looking just
>     at the architecture document, it says (in that section) nothing
>     about the risks from users accepting unknown host keys.  The
>     information is present in diffuse form in 3.1, but it isn't
>     spelled out clearly in one spot.  A possible countermeasure would
>     be some way for a logged-in user to then verify the fingerprint,
>     in a way that a clever mitm proxy would find hard to
>     mimic. Similarly, the draft says little about the security of the
>     endpoint being important.  It's not any one thing; it's that I'd
>     really like SEC-area documents to be better than average, and this
>     isn't up to the standards that I, at least, have been demanding of
>     documents from other areas."
> 
> WG members interested in forward progress of the core drafts should
> take the time to read draft-iab-sec-cons-03 and send suggested text to
> the list..
> 
> - Bill
> 
> 
> 
>

---

From: Simon Tatham <[email-masked]>
Date: Fri, 14 Mar 2003 09:07:45 +0000

> Here is my proposed revision:
[...]
> 11.4 Man-in-the-middle
[...]
>    be mitigated in several fashions:
[...]
>       that is session specific.

It might be worth mentioning explicitly that this is assuming the
solution of a similar key-distribution problem to the one which lays
SSH open to MITM in the first place!

Sure, if you've _already_ copied your public key to the server in a
secure manner, then PK auth is a good way to defeat MITMs. But if
you have _already_ had access to the server in a secure manner in
order to do this, why didn't you just note down the host key
fingerprint while you were there?

Conversely, PK auth doesn't solve your problem if you've never made
a secure connection to the server before, because your very first
connection is vulnerable to MITM and so you can't guarantee that
it's a safe channel through which to copy your public key to the
server - a hypothetical MITM could rewrite the key on the way past
and end up giving the server a public key of his own instead of
yours.

(Of course, this is not an issue if your problem is that you're
connecting to a server you've used before from a new client machine
which doesn't contain your existing host key database. But it isn't
a cure-all, so in a section whose job is to state this sort of thing
explicitly, perhaps it would be a good thing to mention.)

Cheers,
Simon
-- 
Simon Tatham         "That all men should be brothers is a
<[email-masked]>    dream of people who have no brothers."

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 14 Mar 2003 09:54:30 -0500

> SSH open to MITM in the first place!

Generally speaking, the goal of the Security Considerations section
ought to be to:
	- describe residual risks from use of this protocol,
		including potential implementation flaws.
	- describe methods that those residual risks might be
		mitigated, if such methods exist.
	- leave the reader of the document with a clear and accurate
		understanding of what the deployment risks are, so that
		an operator/user can make an informed decision about
		whether to deploy/use the technology in the RFC

IMHO,

Ran

---

From: Simon Tatham <[email-masked]>
Date: Fri, 14 Mar 2003 14:58:58 +0000

[...]
>       whether to deploy/use the technology in the RFC

Quite so. And hence, if PK authentication is a useful means of
mitigating host key risks in some but not all situations, it seems
important to the reader's clear and accurate understanding that they
should be aware of which situations are which.

Cheers,
Simon
-- 
Simon Tatham         "I'm cross. I'm going to have a tantrum.
<[email-masked]>    <pause> How do I start?"            - my uncle

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 15 Mar 2003 20:16:36 -0500

In message <[email-masked]>, "Joseph Galbraith
>Well, I'm not sure if this is what we need or not, but
....
>Is this what is needed, or am I way off track?

Very nice.  There's one more point I want mentioned, aside from
Bill's suggestions:  a caveat about the dangers of using forwarding
(of ports, X11, or the authentication agent) to machines that
aren't trustworthy.  (Some of that should, perhaps, be in -connect
instead, since there's already related text.)

One more thing, and this is probably my own experiences talking:
suggest that implementations provide a simple way for a logged-in
client to retrieve the fingerprint of the host's key, as well as
the stored fingerprint.  Furthermore, this should be done in a
way that's hard for a MITM attacker to spoof.  The idea is that
sometimes, you log in to a new machine -- but then you'd like to
verify that the key you just accepted indeed matches what's stored
on the new machine.  (Ideally, there's be something involving,
say, the Interlock Protocol, but that's a job for a new document,
not for Security Considerations in this one.)

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 16 Mar 2003 14:42:54 -0500

> instead, since there's already related text.)

So, I'm wondering if it might make more sense to have a single set of
security considerations in the -arch draft, with pointers from the
other three documents.  Like most things security related, they cut
across functional areas, and I really don't want to waste time
trying to get all the hairs perfectly split.

> not for Security Considerations in this one.)

Uhh.. my "mission creep" detector just went off...

I've been reminded that there are several vendors who are waiting for
these documents to come out as RFC's before casting an implementation
into firmware.  

Steve: if you feel strongly that this belongs in the documents, can
you provide sample text for this provision *this week*?

						- Bill

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 16 Mar 2003 19:10:22 -0500

In message <[email-masked]>, Bill Sommerfeld write
>trying to get all the hairs perfectly split.

Always a reasonable option.  Will such a document appear in finite 
time?  The IESG is not fond of approving documents that say "see the 
following non-existent RFC for security considerations" -- but has 
often approved documents that point to existing documents for that 
information.
>you provide sample text for this provision *this week*?

I'll try -- and if I don't, I won't object to you shipping it the week 
after.  I'm certainly *not* suggesting that you design something based
on the Interlock protocol now.  In fact, I'd object you tried to...

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 16 Mar 2003 19:19:00 -0500

> often approved documents that point to existing documents for that 

The -arch draft, draft-ietf-secsh-architecture-13.txt,
is currently part of the core drafts hairball before the IESG at this
moment.

					- Bill

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 16 Mar 2003 20:36:56 -0500

In message <[email-masked]>, Bill Sommerfeld wr
>is currently part of the core drafts hairball before the IESG at this

Right, but currently the security considerations information is split 
across many different documents.  You'd have to collect it in that one 
place -- which would be a good idea.

---

From: Markus Friedl <[email-masked]>
Date: Mon, 17 Mar 2003 09:34:09 +0100

> and end up giving the server a public key of his own instead of

as far as i understand pk auth with ssh v2, i think
that pk auth allows you to detect MITM because in this
case the authentication will always fail (as opposed
to ssh v1). (but i could be too tired to get this right)....

-m

---

From: "Joseph Galbraith" <[email-masked]>
Date: Sat, 29 Mar 2003 08:33:25 -0800

All right; here is version two, to be added to 
the architecture draft.

I'd appreciate feedback.

- Joseph

-----

   In order to make the entire body of Security
   Considerations more accessible, Security
   Considerations for the transport, authentication,
   and connection documents have been gathered here.

   The transport protocol [1] provides a secure encrypted
   channel over an insecure network.  It performs server
   host authentication, key exchange, encryption, and
   integrity protection.  It also derives a unique
   session id that may be used by higher-level protocols.

   The authentication protocol [2] provides a suite of
   mechanism which can be used to authenticating the client
   user.  Individual mechanisms specified in the in
   authentication protocol use teh session id provided
   by the transport protocol and/or depend on the security
   and integrity gaurentees of the transport protocol.

   The connection protocol [3] specifies a mechanism
   to multiplex multiple streams [channels] of data over
   the secure transport. It also specifies channels for
   accessing an interactive shell, for 'proxy-forwarding'
   various external protocols over the secure transport
   (including arbitrary TCP/IP protocols), and for
   accessing secure 'subsystems' on the server host.

11.1 Transport

11.1.1 Confidentiality 

   With ciphers operating in CBC mode is theoretically
   vulnerable to choosen cipher-text attacks because of
   the high predicability of the start of packet sequence.
   However, this attack is still relatively hard enough, and
   requires a sufficiently high number of packets, to be safe
   in the short term.  Ciphers with larger block sizes are
   less vulnerable the ciphers with smaller block sizes.
   [Is this true?]

   Effort is underway to standardize the use of CTR mode
   ciphers in the SSH protocol.  When this work is completed,
   implementors SHOULD support it.
   
   In addition, the CBC mode attack can be mitigated by
   ensuring the an SSH_MSG_IGNORE packet preceeds any real
   data at the start of a TCP packet.
   [Is this true?  26 of the 32 length bits can probably
   be reliably guessed to be 0.  One or two of the pad
   length bits are likewise reliably guessed as 0.  The
   packet type is known.  26 of the length field of the
   string in an ignore packet are known. So 26 + 2 + 8 + 16 = 
   52 of the first 64 bits are reliablely known (or 62 of
   the first 128 bits) -- my understanding is hazy-- is
   this applicable to the vulnerability?]

11.1.2 Data Integrity

   Because MACs use a 32 bit sequence number, they may
   start to leak information after 2**32 packets have
   been sent.  However, following the rekeying
   recomendations should prevent this attack.
   The transport protocol [1] recommends rekeying after
   one gigabyte of data, and the smallest possible
   packet is 16 bytes. Therefore, rekeying should happen
   after 2**28 packets at the very most.

11.1.3 Replay

11.1.4 Man-in-the-middle

   However, this does assume that the public-key has
   been distributed to the server host in some secure
   fashion before the first SSH connection can be made.

   Server administrators are encouraged to make host key
   fingerprints available for checking by some means whose
   security does not rely on the integrity of the actual host
   keys.  Possible mechanisms include secured Web pages, the DNS
   [draft-ietf-secsh-dns], physical pieces of paper, etc.
   Implementors should provide recommendations on how best to do
   this with their implementation.

11.1.5 Denial-of-service

   attacks because an attacker can force the server to go through
  
11.1.6 Covert Channels

11.2 Authentication Protocol

   The purpose of this protocol is to perform client user
   authentication.  It assumed that this runs over a secure transport
   layer protocol, which has already authenticated the server machine,
   established an encrypted communications channel, and computed a
   unique session identifier for this session.  The transport layer
   provides forward secrecy for password authentication and other
   methods that rely on secret data.

   The server may go into a "sleep" period after repeated unsuccessful
   authentications to make key search harder.

   Several authentication methods with different security
   characteristics are allowed.  It is up to the server's local policy
   to decide which methods (or combinations of methods) it is willing to
   accept for each user.  Authentication is no stronger than the weakest
   combination allowed.

11.2.1 Weak Transport

   If the transport layer does not provide encryption, authentication
   methods that rely on secret data SHOULD be disabled.  If it does not
   provide MAC protection, requests to change authentication data (e.g.
   password change) SHOULD be disabled to avoid an attacker from
   modifying the ciphertext without being noticed, rendering the new
   authentication data unusable (denial of service).

11.2.2 Debug messages

   Special care should be taken when designing debug messages.  These
   messages may reveal surprising amounts of information about the host
   if not properly designed.  Debug messages can be disabled (during
   user authentication phase) if high security is required.

11.2.3 Local security policy

   Authentication is always a delicate security operation.
   Implementor MUST not only ensure that the credentials
   given validate the professed user, but also that the
   local policy of the server hosts allows the user the
   access requested.

   In particular, because of the flexible nature of the
   SSH connection protocol, it may not be possible to determine
   this completely at the time of authentication, because
   the kind of service being requested is not yet clear.

   For example, local policy might allow a user to access
   files on the server, but not start an interactive shell.
   However, during the authentication protocol, it is not
   known whether the user will be accessing files or
   attempting to use an interactive shell, or even both.

   In any event, local security policy for the server
   host MUST be applied and enforced correctly.

11.2.4 Public key authentication

   The use of public-key authentication assumes that the
   client host has not been compromised.
   
   This risk can be mitigated by the use of passphrases
   on private keys; however, this is not an enforcable
   policy.  The use of smartcards, or other technology
   to make passphrases an enforcable policy is suggested.

   The server could require both password and public-key
   authentication, however, this requires the client
   to expose its password to the server (see section on
   password authentication below.)

11.2.5 Password authentication

   The password mechanism of specified in the authentication
   protocol assumes that the server has not been compromised.
   If the server has been compromised, using password
   authentication will reveal a valid username / password
   combination to the attacker, which may lead to further
   comprimises.

   This vulnerability can be mitigated by using an alternative
   form of authentication.  For example, public-key authentication
   makes no assumptions about security on the server.

11.2.6 Host based authentication

   Host based authentication assumes that the client
   has not been compromised.  There are no mitaging
   strategies, other than to use host based authentication
   in combination with another authentication method.

11.3 Connection protocol

11.3.1 End point security

   End point security is assumed by the connection protocol.
   If the server has been compromised, any terminal sessions,
   port forwarding, or systems accessed on the host are comprimised.
   There are no mitigating factors for this.

   If the client end point has been compromised, and the server
   fails to stop the attacker at the authentication protocol,
   all services exposed (either as subsystems or through forwarding)
   will be vulnerable to attack.  Implementors SHOULD provide
   mechanisms for administrators to control which services
   are exposed to limit the vulnerability of other services.

   These controls might include controlling which machines and
   ports can be target in 'port-forwarding' operations, which
   users are allowed to use interactive shell facilities, or
   which users are allowed to use exposed subsystems.

11.3.2 Proxy forwarding

   The ssh connection protocol allows proxy forwarding
   of other protocols.  The proxy forwarding functionality
   can be used to circumvent firewall protections.  Implementors
   SHOULD provide a mechanism to disable to administratively
   control the proxy forwarding funcitonality.

   In addition, a reverse proxy forwarding functionality
   is available, which again can be used to bypass firewall
   controls.

   As indicated above, end-point security is assumed during
   proxy forwarding operations.  Failure of end-point security
   will compromise all data pass over proxy forwarding.

11.3.3 X11 forwarding

   Another form of proxy forwarding provided by the ssh
   connection protocol is the forwarding of the X11 protocol.

   Implementors of the X11 protocol SHOULD implement the
   magic cookie spoofing, to prevent unauthorized use of
   the proxy.

   X11 forwarding relies on end-point security.  If end-point
   security has been compromised, X11 forwarding will allow
   any attack against the X11 server possible locally.

   Users and administors should, as a matter of course, use
   X11 security mechanism to prevent unauthorized use of
   the X11 server.

---

From: Eric Rescorla <[email-masked]>
Date: 29 Mar 2003 09:14:16 -0800

Some detailed comments,

>    provides confidentiality.  Older, smaller ciphers, such
Why do you say "smaller". How is 3DES smaller than AES?

>    such as twofish, serpent, or AES over blowfish, 3des and
Why would you recommend twofish and serpent over 3DES?
3DES has received vastly more analysis than either.

>    less vulnerable the ciphers with smaller block sizes.
What attack are you talking about here? The Rogaway attack?
Perhaps you need a citation and some explanation?

>    data at the start of a TCP packet.
A TCP packet? How is the TCP mapping relevant?

>    been sent. 
You should be specific here about how they leak data.

>    to prevent replay of packets form previous sessions.
                                  ^^^^
from.

>    also prevents the insertion or deletion of packets.
I'm not sure this is true if the MAC is disabled.

>    control the proxy forwarding funcitonality.
This sentence is ungrammatical.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: "Howard Chu" <[email-masked]>
Date: Sat, 29 Mar 2003 09:25:49 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
Of Eric Rescorla

> >    the high predicability of the start of packet sequence.

Likewise. Aside from "chosen" it's still unparsable.

> >    ensuring the an SSH_MSG_IGNORE packet preceeds any real
		    ^^^ that

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 31 Mar 2003 08:08:59 -0800 (PST)

Hi,

My attempts at resolution in-line.  I will note that I make no claim to
cryptographic abilities.  I've merely tried to work Joseph's thoughts
into a hopefully more palatable contribution.  :-)

> 3DES has received vastly more analysis than either.

Replace with:

   It is beyond the scope of this document and the Secure Shell Working
   Group to analyze or recommend specific ciphers other than the ones
   which have been established and accepted within the industry.  At the
   time of this writing, ciphers commonly in use include 3DES, ARCFOUR,
   twofish, serpent and blowfish.  AES has been accepted by cryptographic
   experts as being stronger than most of the other ciphers in use today
   and it is being implemented in other security protocols as it is within
   SSH.  As always, implementors and users should check current literature
   to ensure that no recent vulnerabilities have been found in ciphers used
   within products.  Implementors should also check to see which ciphers
   are considered to be relatively stronger than others and should
   recommend their use to users over relatively weaker ciphers.  It would
   be considered good form for an implementation to politely and
   unobtrusively notify a user that a stronger cipher is available and
   should be used when a weaker one is actively chosen.  Implementors may
   wish to offer relatively weaker ciphers in their products for
   interoperability but should strive to depricate them as soon as
   possible.

   The "none" cipher is provided for debugging and should never be used
   except for that purpose.  It's cryptographic properties are
   sufficiently described in RFC 2410.

[This last part should probably be worked into the preceding paragraph in
Joseph's original proposal - paragrph 1 of section 11.1.]

> Perhaps you need a citation and some explanation?

Replace with:

   The relative merits of these and other ciphers may also be found in
   current literature.  Two references that may provide information on the
   subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER].  Both of these
   describe the CBC mode of operation of certain ciphers and the weakness
   of this scheme.  Essentially, this mode is theoretically vulnerable to
   chosen cipher-text attacks because of the high predictability of the
   start of packet sequence.  However, this attack is still deemed
   difficult and not considered fully practicable especially if relatively
   longer block sizes are used.

   [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley
   and Sons Publisher, 1996

   [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in
   a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, Prentice
   Hall Publisher, 1995

> A TCP packet? How is the TCP mapping relevant?

   Additionally, the CBC mode attack may be mitigated through the
   insertion of packets containing SSH_MSG_IGNORE.  This technique may be
   used to obfuscate the relative positions of the enciphered message and
   its use is encouraged.  Beyond that, an effort is currently underway to
   standardize the use of the CTR mode of operation in ciphers used in the
   SSH protocol.  When that work is completed, implementors SHOULD support
   it as that will obviate the CBC mode attack.

> This sentence is ungrammatical.

Replace with:

   The SSH connection protocol allows for proxy forwarding of other
   protocols such as SNMP, POP3, and HTTP.  This may be a concern for
   network administrators who wish to control the access of certain
   applications by users located outside of their physical location.
   Essentially, the forwarding of these protocols may violate site
   specific security policies as they may be undetectably tunneled
   through a firewall.  Implementors SHOULD provide an administrative
   mechanism to control the proxy forwarding functionality so that
   site specific security policies may be upheld.

> -Ekr

Thanks,
Chris

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 31 Mar 2003 11:10:30 -0500

Overall, a very good start.  Specific nits noted inline.

Ran
[email-masked]

On Saturday, Mar 29, 2003, at 11:33 America/Montreal, Joseph Galbraith  
>    channel over an insecure network.  It performs server

s/a secure encrypted channel/a confidential channel/

"encryption" is the mechanism.
"confidentiality" is the property.

>    user.  Individual mechanisms specified in the in

s/user./user to the server./

>    authentication protocol use teh session id provided

s/teh/the/

>    and integrity gaurentees of the transport protocol.

s/guarentees/guarantees/

>    the secure transport. It also specifies channels for

s/secure transport/confidential and authenticated transport/

>    such as twofish, serpent, or AES over blowfish, 3des and

s/MAY/might/

The capitalised "MAY" as used in IETF documents related only
to permission, not to possibilities.  In the sentence above,
the apparent meaning is that some ciphers might be less
desirable than others, so "might" is a more clear choice
and capitalised "MAY" is a clearly bad choice.

>    the high predicability of the start of packet sequence.

Not a sentence; please rephrase.

Also, please consider adding a bibliographic reference
to some paper, article, or book in the published literature.

>    less vulnerable the ciphers with smaller block sizes.

See previous comment.

>    implementors SHOULD support it.

Premature.  Suggest deleting those 2 sentences for now.
The issue can be revisited later if/when CTR mode is specified
and there is some clear consensus on whether those specs
are solid.

>    this applicable to the vulnerability?]

We ought avoid making claims unless we are certain that
they are valid.  Again, it is pleasant to cite some
document, paper, or book in the public literature for
published claims such as in this document.

>    Because MACs use a 32 bit sequence number, they may

s/may/might/

>    after 2**28 packets at the very most.

s/should happen/SHOULD hapen/

In this case, one appears to be trying to levy implementation
guidance, so capitalisation is appropriate.

>    session in the hash used to produce session keys.

Is it random or pseudo-random ?
Does the difference matter in this case ?

>    also prevents the insertion or deletion of packets.

Citations would be pleasant for these claims.

>    This protocol makes no assumptions nor provisions for

s/no/neither/

>       on the _first_ connection to a given server.

Narrow *which* window ?
Intended meaning is not crystal clear above.

>       can not create a valid signature because he does not

Is this really true and sufficient ?

>       to the protocol may provide better mechanisms for dealing

s/may/might/

This is not dealing with permissions, but with possibilities.

>    this with their implementation.

s/should provide/SHOULD provide/

Again, this is providing implementation guidance, so ought to be
capitalised.

>    Use of this protocol without reliable association

association of what/whom ?

>    protocol should keep this possibility in mind.

???  s/protocols running/applications running/ ???
>    methods that rely on secret data.

"perfect forward secrecy" or "forward secrecy" ?

>    If the transport layer does not provide encryption, authentication

s/encryption/confidentiality/

>    local policy of the server hosts allows the user the

Propose edit of paragraph above to:
	Implementer MUST ensure that the credentials provided
	validate the professed user and also MUST ensure that
	the local policy of the server permits the user the
	access requested.

>    the kind of service being requested is not yet clear.

Unclear antecedent "this".

>    has not been compromised.  There are no mitaging

s/mitaging/mitigating

>    magic cookie spoofing, to prevent unauthorized use of

Add citation for "magic cookie spoofing".

>    X11 security mechanism to prevent unauthorized use of

Which "X11 security mechanism" is meant ?
Also, please add a citation for that mechanism.

------------------------------------------------------------------------ 
---

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 31 Mar 2003 17:21:18 -0500

> "confidentiality" is the property.

a nit on a nit: 

It's probably also worth adding something about "integrity-protected"
as well here.

					- Bill