[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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

Linn, John writes:
> 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.

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">
<input type="text" size=8 name="username">
SecurID code:
<input type="password" size=8 name="securidcode">

Now when the user fills this in (or the program which knows that this
host is using username/securidcode will directly go to page
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");
kivinen@xxxxxx                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/