Subject: SecurID(r) tokens and multi-step authentication exchanges

From: "Linn, John" <[email-masked]>
Date: Wed, 13 Dec 2000 09:43:49 -0500

As an input to the ongoing comparison between PIC and getcert, I'd like to
point out an aspect which may not be widely recognized. RSA Security's
SecurID tokens have certain operational cases (e.g., token
resynchronization, PIN changes) where a user is prompted for and must
provide a series of inputs in order to complete a single authentication
transaction.  In order to fully support these tokens, therefore, it's
necessary to be able to carry multi-step transactions, even though these
cases arise only on infrequent occasions in ordinary use. Informational
RFC-2808 provides more explanation and examples, in the context of SASL
integration for the tokens.   

--jl

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Dec 2000 20:56:20 +0200 (EET)

> integration for the tokens.   

If we allow html-forms authentication in the getcert, then it is easy
to do. In that case we have session that looks like this:

First html page: http://www.foo.bar.ex/cgi-bin/getcert
----------------------------------------------------------------------
...<Some graphics, logos etc>...
You are about to log in the foo.bar company's VPN, unauthorized use
forbidden ...

Username:     [                ]
SecurID code: [                ]

<we can also show challenge etc here>
----------------------------------------------------------------------
The html code would be:
----------------------------------------------------------------------
...
<form method="get">
Username:
<input type="text" size=8 name="username">
<br>
SecurID code:
<input type="password" size=8 name="securidcode">
<br>
</form>
...
----------------------------------------------------------------------

Now when the user fills this in (or the program which knows that this
host is using username/securidcode will directly go to page
http://www.foo.bar.ex/cgi-bin/getcert?username=kivinen&securidcode=123456
they will get back next page saying:

----------------------------------------------------------------------
Your ping code is out of sync, give another.

Username:      kivinen
SecurID code: [                  ]
----------------------------------------------------------------------
Again the html code is something that is similar, except now the
securidcode name is propably different.

If the program received this page it would search for the input fields
and seeing that the name is "nextpin" instead of securidcode, it knows
it needs to ask next pin instead.

Parsing the html file is quite easy when you just need to find out the
form field names is quite easy, because you don't really need to
completely parse the file, you can just do quick "partial" parse
through the file and find out the name attributes in the input tags.

For example the following perl code will do it:
----------------------------------------------------------------------
#!/usr/local/bin/perl -w

undef $/;
# Split the page to text,<tag>,text,<tag>,text,...,<tag>,text list
@page = split(/(<[^>]*>)/, <>);
$len = $#page;

# Loop through all tags, odd numbers in the array are tags, even are
# the text itself.
for($i = 1; $i <= $len; $i += 2) {
    # remove < from the beginning and > at the end
    $item = $page[$i];
    $item =~ s/^<//g;
    $item =~ s/>$//g;
    # Find the input tag and name attribute from it
    if ($item =~ /input.*\s+name=(?:\"([^\"]*)\"|\'([^\']*)\'|(\S+))/i) {
      $name = $1 if (defined($1));
      $name = $2 if (defined($2));
      $name = $3 if (defined($3));
      print("name = $name\n");
    }
}
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Yaron Sheffer" <[email-masked]>
Date: Thu, 14 Dec 2000 08:04:03 +0200

Hi Tero,

in my opinion your proposal reduces the security of getcert, in that it now
relies on ASP scripts, not just TLS and HTTP authentication. I think from a
security point of view, it is better to support the majority of
authentication methods and "most" of SecureID functionality, than to
introduce such a major hole.

Just to clarify: EAP, the authentication method underlying PIC, does support
multiple rounds, and thus could be used for the SecureID Next PIN mode, etc.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tero Kivinen
Sent: Wednesday, December 13, 2000 8:56 PM
To: Linn, John
Cc: [email-masked]
Subject: SecurID(r) tokens and multi-step authentication exchanges

Username:     [                ]
SecurID code: [                ]

Username:      kivinen
SecurID code: [                  ]

undef $/;

---

From: Ghislaine Labouret <[email-masked]>
Date: Thu, 14 Dec 2000 09:23:53 -0800

On Thu, 14 Dec 2000 08:04:03 +0200, Yaron Sheffer wrote:

> relies on ASP scripts, not just TLS and HTTP authentication. 

Who said it had to be done with ASP scripts? The server can implement
SecurID authentication in various ways (more or less secure, depending
on the programmer's skills). For example, there is an implementation of
SecurID auth using HTTP/HTML, as an Apache module :
http://persoweb.francenet.fr/~pasty/mod_securid/

> [mailto:[email-masked]]On Behalf Of Tero Kivinen
[...]
> to do. 

The current GETCERT spec is, apparently deliberately, not very specific
about how the various legacy authentication schemes can be accommodated.
The "Authentication Techniques" paragraph (reproduced below) insists, in
my opinion, too much on classical HTTP authentication and RADIUS: the
back-end server could be an LDAP one for example, cookies or CGI
parameters could be used to convey the user's auth data, and the process
could be composed of more than 2 phases. Without mandating any scheme,
couldn't the draft give examples/pointers or recommendations on how
various legacy authentication schemes could be implemented?

| 5. Authentication Techniques
| 
|    Although this document is carefully agnostic about the user
|    authentication techniques to be used, there are two underlying
|    assumptions.  First, we assume that the authentication is actually
|    being performed by a back-end RADIUS server, over the TLS HTTP
|    connection, with its accompanying database.  Second, we wish to
|    support a variety of common authentication techniques, including
|    ordinary passwords, time-varying tokens, and challenge/response
|    tokens.  All are believed to be accommodated by this framework.
|    Finally, we rely on this client and server authentication so that the
|    SCEP assumptions on CA root certificate distribution and subjectName
|    checking are automated.
| 
|    Requests for certificates must be authenticated.  Since we prescribe
|    HTTP, HTTP authentication mechanisms -- under protection of TLS --
|    MUST be used.  Specifically, the request will generally include an
|    appropriate Authorization: line, using whatever form of
|    authentication is locally preferred.  If it does not, the server MUST
|    return a 401 error line, per [RFC2616] and [RFC2617]; the client MUST
|    then resubmit the request with the appropriate Authentication: line.
|    (This two-phase process is permitted in order to support
|    challenge/response forms of authentication.)

--
Ghislaine Labouret, Network security consultant
Hervé Schauer Consultants (HSC) - http://www.hsc.fr/
Phone (+33)-141-409-700 - Fax (+33)-141-409-709

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Dec 2000 19:49:27 +0200 (EET)

> relies on ASP scripts, not just TLS and HTTP authentication. I think from a

ASP scripts? I didn't mention anything about APS scripts. I was
talking about the server sending web page and processing normal form
with normal methods available for it. I myself definately would not
use ASP for this kind of system.

Anyways, I propably wouldn't trust normal web-server either for this
kind of service, but I would use minimal web-server instead. 

> introduce such a major hole.

If sending forms to the web-server is a security hole, then I think
you should use some other web-server. I is used by all web banking
systems I have seen, it is used by almost all other web system that
requires authentication too. Nobody is using http-authentication
anymore. I don't even remember when I last time saw real
http-authentication request anywhere. 

> multiple rounds, and thus could be used for the SecureID Next PIN mode, etc.

But it needs much bigger piece of code than is needed to be made
secure than that small piece of code that is required to parse and
verify the password sent in the html-form. If you do not trust that
people can write secure ~50 line program parsing and checking the
html-form, how can you trust they can write ~5000 line program to run
PIC?
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Yaron Sheffer" <[email-masked]>
Date: Thu, 14 Dec 2000 18:51:56 +0200

Hi Tero,

I'm not sure I want to be drawn into a theological discussion, but anyway.

For a security protocol, you want to use:

1. Standard building blocks.
2. Building blocks that are (or have been) implemented with security in
mind.

(1) would point you towards SASL or EAP, rather than HTTP plus CGI
scripting.

(2) implies you want to reduce your reliance on "general" standards that may
have hidden security problems, either in protocol or implementation. You can
reasonably expect that a typical *implementation* of IKE is more secure than
a typical implementation of HTTP.

There is no reason why EAP should be more complex than any XAuth
implementation. They are semantically equivalent. Both are probably worth
much less than 5,000 lines of code.

Thanks,
	Yaron